Runtime: feed provider_invalidation_proof so a partial-401 browser-session run prompts for sign-in #647

After #636, a browser-session connection gets a sign-in prompt only when a run fails with a session or 401 reason (credentialsValidCondition, reference-implementation/runtime/connection-health.ts:2574-2586). A run that keeps going and reports per-item 401s as detail gaps no longer prompts. Section 5.11 forbids acting on that connector claim, and the runtime has no evidence of its own to replace it.

The runtime-side path exists but nothing feeds it. browserSessionRepairAuthorized (connection-health.ts:2627) accepts a verified provider_invalidation_proof through ComputeConnectionHealthInput.browserSurfaceRepair. ref-control.ts passes browserSurfaceRepair through to the projection (:5710, :5966), but no production caller sets it, so the value is always null. Only connection-health.test.ts builds a proof.

Effect: a connection whose session lapses partway through a run shows a failed run and coverage gaps on every scheduled run, with no sign-in prompt, until some run fails terminally.

Proposal: have the runtime record a provider invalidation proof from its own observation, for example the browser surface landing on the provider's sign-in page or the runtime's own session probe getting a 401. Persist the proof per connection and load it into browserSurfaceRepair when the connection summary is built.

Acceptance (red first): a connector-summary test through ref-control.ts, not computeConnectionHealth directly. It uses a browser-session-bound connection with a durable, verified provider invalidation proof and a latest run that reported only per-item 401 gaps. It asserts a browser_session reauth action. It fails on main after #636 because the proof never reaches the projection. A second case asserts that the same connection with no proof gets no reauth action, which keeps the Section 5.11 rule.