Channels: function-form approvers fail closed after a restart

[LinuxDevil]

Found while working M10a (#233), listed there as out of scope.

docs/channels.md (Security note): "A function approvers fails closed when the process does not know the pending call (after a restart); use the list form or the default for approvals that must survive one."

mayApprove() (src/channels/channelSupport.ts) gives a function approvers the pending request through ctx.approval(id), which only knows this process's pauses (agent.approvals.list()). After a restart the function cannot be consulted, so the click is refused.

Possible direction: the approval store already holds the PendingApproval (and the snapshot); a read method on ApprovalStore (or on agent.approvals) that returns a pending record by id, without resolving it, would let ctx.approval(id) answer after a restart. That touches the ApprovalStore interface (every store implementation), so it may need an owner decision.

[aetherxeg-source]

One invariant that may help shape the store API is:

restart-safe approval requires restart-safe authorization inputs

Persisting the pending approval is only half of the contract if the function-form approver depends on request facts that currently live only in process memory. The durable record should make the authorization decision reproducible after restart without silently changing what is being evaluated.

I would preserve an immutable approval-request snapshot containing at least:

approval_id
session/run generation
requesting principal (if any)
tool/effect identity
args digest or bounded canonical args
created_at / expiry
policy generation or evaluator identity

Then restart semantics can be explicit: either evaluate the current approver function against the original request facts, or evaluate against a captured policy generation if that is the intended model. What should not happen is ctx.approval(id) becoming incomplete after restart and that absence being indistinguishable from an intentional denial.

A useful regression is: pause P under policy generation G1, restart, change authorization state to G2, then resolve P. The result should be deterministic and auditable about both the immutable request snapshot and the evaluator/policy generation used for the decision.