confirm_gate leaves the handler call outside _refusal_reaches_the_caller #371

What happens

confirm_gate closes its _refusal_reaches_the_caller() block before invoking the handler, so a domain refusal raised inside continuum_confirm would reach the client as the opaque Error executing tool continuum_confirm instead of its own message.

The difference

guard calls the handler inside the context manager:

with _refusal_reaches_the_caller():
    auth.verify(caller, token_from(ctx))
    policy.require(caller, fn.__name__)
    return fn(*args, **kwargs)

confirm_gate does not:

with _refusal_reaches_the_caller():
    confirm_auth.verify(token_from(ctx))
    policy.require(caller, fn.__name__)
return fn(*args, **kwargs)

continuum_confirm calls ctx.storage.append_event(run_id, ...), which raises RunNotFound for an unknown run. Under guard that becomes a ToolError carrying no such run: '<id>'. Here it stays a bare domain exception, which is the case _refusal_reaches_the_caller documents as needing conversion: "a run that does not exist. Each answer is only useful if the caller is told which one it was."

Severity

Latent. Not reproducible in the default configuration, because confirmation refuses every caller before the body runs when CONTINUUM_MCP_CONFIRM_TOKEN is unset. It becomes reachable as soon as an operator opts in, which is exactly when a confirm call against a mistyped run id is likely.

Found by inspection while auditing the MCP surface, not by observation. Flagging it rather than filing it as reproduced.

Suggested fix

Move return fn(*args, **kwargs) inside the with block, matching guard. The authenticate-before-authorize ordering that the surrounding comment protects is unaffected.

A test asserting that both decorators convert a domain exception raised by the handler body would keep the two from drifting again.