Browser adapter: distinguish input refusal from an uncertain outcome #439

The Browser adapter should report whether an operator input was refused before dispatch or may already have run. Runtime owns reconciliation and retry decisions; the adapter supplies truthful transport evidence.

At #421 head 21e7f84, capsules/browser-engine-adapter/src/main.rs:2124–2137 maps every error from supervisor_control_json_bounded to operator_outcome_uncertain. That helper also returns errors before dispatch, including socket validation and connection failure (src/supervisor.rs:308–319). The blanket mapping loses that distinction.

Done means:

• Preserve typed, definite refusals when the adapter can prove the effect was not dispatched. Keep uncertainty for a partial write, lost acknowledgement or response that cannot establish the outcome.
• Preserve Keep deferred Browser input with its owning page #421's 503 plus operator_outcome_uncertain behavior for uncertain input. Retain page, principal and lease checks and the existing Runtime effect path.
• Test validation refusal, connection refusal, a confirmed provider refusal, partial dispatch, lost acknowledgement and success through the adapter. Assert exact status/code and effect counts; reverting classification makes a test fail.
• Prove uncertain input is reconciled before any retry and that a retry cannot silently repeat an effect.

Follow-up to #421; coordinate with #290's operator contract owner.

Acceptance record:

• Candidate: pending.
• Exercised checks: source inspection only.
• Review links: Keep deferred Browser input with its owning page #421 Round 4 follow-up.
• Installed release evidence: pending.
• Remaining gate: implementation, regression/control tests, applicable reviews and installed Browser acceptance.
• Next owner: Browser adapter/operator owner, unassigned.