Distinguish session page observation refusal branches

[ey1492]

Problem

The session/page controller maps two different observation outcomes to session/not-found: a missing observed session and an observation whose header has no cwd. Both paths return the same error details. A client cannot identify which condition caused the refusal.

Question

Would maintainers accept a bounded reason in the existing typed session/not-found error details for these two controller branches? The reason would describe only the observed branch. It would not claim that a file was lost or that a session can be recreated.

A candidate change would preserve the existing error code and control flow, use a closed enum, and exclude paths, IDs, raw exceptions, and session contents. Synthetic tests could cover both branches and the RPC error serialization. Other producers of session/not-found would not claim a branch they did not observe.

Does this fit the Session API contract? If so, which package and release process should own the change?

[ey1492]

The repository contribution guidance asks for a same-repository Issue reference, but Issues are disabled for this repository. What contribution and release path should an external contributor use for this diagnostic?

[ey1492]

@Magolor, your recent session runtime projection work appears related. Could you or a maintainer advise who owns the session/page contract and the supported same-repository issue and release path when Issues and pull requests are disabled here? A local synthetic candidate distinguishes only the two observed branches using a closed enum and preserves the existing refusal code and flow. It does not claim a root cause or include session content, paths, or identifiers. No upstream write or release access is assumed.

[ey1492]

Follow-up on current master f3803c96974ad4a94195fb97e5c637e9c2a3afe3: history now lives in src/history/controller.ts. The events handler maps a caught session/not-found through rejectNotFound, so adding a bounded branch detail only to the lower observation error would lose it during remapping. A candidate would need to preserve the intended detail at that boundary while maintaining the existing address-specific subagent behavior. Would that fit the intended API contract?