bug(server integration): adopt Praxis-managed subrequest policy reloads

[franciscojavierarceo]

Problem

AI callouts using the server-provided SubRequestClient can retain
the startup body_limits.max_response_bytes ceiling after a
successful dynamic configuration reload.

This makes reload appear successful while affected callouts continue
enforcing stale runtime policy.

Ownership and status

This issue tracks Praxis AI adoption and AI-visible regression
coverage. The underlying server composition, client policy, and
reload lifecycle are generic Praxis concerns tracked upstream by:

• Enhancements EPIC praxis-proxy/praxis#1076
• Embeddable Server Composition proposal PR praxis-proxy/enhancements#10

Implementation remains blocked until the proposal is accepted and
the required Praxis core API is available. Praxis AI should not
introduce its own reloadable client handle, require callers to
coordinate handle identity, or duplicate generic server, watcher,
and reload lifecycle code.

Scope

• Adopt the Praxis-managed server composition and subrequest-policy
  API in the Praxis AI server.
• Remove the duplicated AI lifecycle plumbing superseded by that
  upstream API.
• Ensure every AI filter that receives the shared SubRequestClient
  inherits the active server-managed response ceiling. Current
  consumers include:
  • anthropic_web_search
  • openai_file_resolve
  • openai_file_search_callout
  • openai_responses_compact
  • openai_web_search
• Keep connector settings that require restart explicit and
  consistently diagnosed.
• Document which subrequest settings are reloadable versus
  restart-required.

Out of scope

• Defining or implementing the upstream Praxis composition API.
• Implementing atomic pipeline, activation, and runtime-policy
  publication in Praxis core.
• Defining policy behavior for listeners retained across a
  topology-changing reload.
• Unifying Praxis startup, validation/dump, and reload construction
  paths.
• Making connection-pool, connection-cap, or circuit-breaker
  configuration dynamically reloadable unless the upstream design
  explicitly supports it.

These generic guarantees belong to Enhancements EPIC praxis-proxy/praxis#1076 and its
Praxis implementation issues.

Acceptance criteria

• Praxis AI uses the supported Praxis composition and policy API
  without copied generic server, watcher, or reload-policy plumbing.
• Reload with a smaller max_response_bytes value and prove
  file-resolve and web-search callouts enforce the smaller ceiling.
• Reload with a larger value and prove an allowed response is no
  longer rejected by the startup ceiling.
• All shared-client AI factories consume the Praxis-managed client
  without an AI-specific reload handle or handle-identity
  requirement.
• Operator documentation distinguishes reloadable response limits
  from restart-required connector settings.

Related

• Enhancements EPIC praxis-proxy/praxis#1076 — coordinating server-composition enhancement
• Enhancements proposal PR praxis-proxy/enhancements#10 — initial What/Why proposal
• Epic: Consistent and safe outbound AI callout configuration #694 — consistent and safe outbound AI callout configuration
• bug(server): honor runtime subrequest circuit-breaker configuration #695 — honor runtime subrequest circuit-breaker configuration; another server-lifecycle integration symptom
• fix(server): rebuild client-aware AI filter factories on config reload #723 — AI-local implementation attempt, superseded by the ownership decision described above
• Preserve stateful filter state across hot-reload pipeline rebuilds #215 — state preservation across hot reload (closed; different concern)
• refactor(apis): upgrade praxis-core for bounded callout reads #454 — bounded callout reads (closed)

[Artemon-line]

I would like to take this one.
Thanks!

[leseb]

I think I saw this before and decided not to fix it 😅