`filterRequest` updates can remain stale on established TLS tunnels

[StellarRequiem]

On source commit bcad38810efcc2b7342bbc6ec26d15b7bbbabcfb, a
live SandboxManager.updateConfig() replacement of network.filterRequest
updates manager state but is not consistently applied to subsequent decrypted
requests on an already-established TLS-terminated HTTP/1.1 tunnel.

In a local same-tunnel control, the baseline invoked the old allow callback for
both requests. A candidate repair resolved the callback per decrypted request,
so the first request used the old allow policy and the second used the new deny
policy. The same stale behavior was reproduced when the tunnel existed before
any callback was installed.

The current documentation does not explicitly promise that this callback is
hot swappable. Either of these behaviors would remove the silent mismatch:

1. apply the replacement callback to later requests on existing tunnels; or
2. reject or warn on a live callback change that cannot be enforced there.

I have a five-file candidate patch with focused regression tests. The paired
suite had four baseline-only liveness failures and zero patch-only failures;
the affected TLS and request-filter suites, typecheck, build, and lint passed.
The repository suite also has host-dependent pre-existing failures unrelated
to this change; those residual failures were identical in both arms, so the
meaningful result is the four-to-zero delta and zero patch-only failures.

Would maintainers prefer the tested live-update repair as a pull request, or a
reset-required/rejection contract instead?

Scope

This is a source-pinned local reproduction and engineering proposal. It does
not assert security severity, production prevalence, or external
exploitability.