fix(recovery): keep unknown native outcomes unresolved during recovery #201

What happened

Stability audit finding F02 / P1 (2026-09-27). Priority is an audit recommendation, not a claim of a production incident.

Store.finish() marks a request row done even when its result has status unknown. Recovery inspects the row status without inspecting the stored outcome and classifies it as already_processed.

Isolated reproduction: finish a synthetic request with an unknown native outcome, quarantine the device, then begin recovery. Observed unknown → already_processed, remaining gates [activation], and activation becomes active. No real message or duplicate submission was performed; the demonstrated defect is loss of the uncertainty-review gate.

What you expected

Journal processing completion must remain distinct from confirmed native outcome. Unknown outcomes must remain unresolved until explicit reconciliation; do not imply safe automatic resend.

Environment

• Baseline: published session-peer v1.0.1, commit 55168c3bea5a49e81916fdead57d3634def6b1d6.
• Reproduction: isolated source/tag fixtures; no live message/ACK tests or production mutation.
• Audit environments: macOS arm64, Python 3.14.7; Control tests use Node 22.14.0. Linux evidence is explicitly identified above where applicable.
• Discovery output: not applicable to this fixture; no real session identifiers or credentials are included.

Source evidence

• session_peer_relay/recovery.py#L115
• session_peer_relay/store.py#L295

Acceptance criteria

• Classify stored result.status and applicable retryAllowed semantics, not just requests.status.
• Keep done+unknown and pending cases gated until explicit reconciliation.
• Cover confirmed refused, queued/posted, and malformed/missing outcomes without treating queued/posted as proof of ACK.

Scope and limitations

Related to #118, but this is a newly reproduced recovery boundary, not a request to reopen the entire feature.

Target: v1.0.2 stability work. This issue does not authorize a release or operating-service changes. Offline reproduction establishes the failure mechanism, not attribution of historical #161 incidents.

Checked

• Searched existing issues for duplicates.
• Removed credentials, conversation contents, private paths and real device/session identifiers.
• Used isolated fixtures without weakening inbound permissions.