Approvals: approving a held send skips remaining middleware; approvals store gaps (PR #2 review) #12

Context

Approving a held send skips the rest of the middleware chain, and the approvals store has robustness gaps. Both were flagged in the PR #2 review and are still present at 7b806c6. Related to #4 (ctx.flybot API).

Original feedback

@hsliuustc0106 review (permalink):

• Item 13: "approving a held send calls dispatch() directly and skips every middleware after the one that held it: a policy that would deny (audit, leak prevention) never runs on exactly the messages the owner was told are now vetted."
• P2 Approvals: "pending approvals are unbounded … full request text written to state.json per hold), send text has no size cap, and an approve whose dispatch fails becomes status: 'failed' which the approvals UI never shows … no Retry." Also from P3: FlyBotApprovals.decide has no catch, so a failure becomes an unhandled rejection.

Where (at 7b806c6)

• src/host/hooks.js#L287: approval.exchangeId = await dispatch(approval.request)

Proposed fix

• On approve, resume the chain after the holding middleware and stop on a later deny or hold. Record which middleware held the message.
• Cap the number of pending approvals and the size of stored text. Prune old pending entries.
• Show failed approvals in the UI with a Retry action. Catch errors in decide.

Acceptance criteria

• A test with middlewares [hold, deny]: approving the hold results in a deny, and nothing is dispatched.
• Failed approvals are visible and can be retried.
• Limits are enforced and covered by tests.

Refs: PR #2 (merged), umbrella #3. Verified against Birfy/FlyBot flybot-plugins tip 7b806c6.