feat(ri-exchange): list and resolve stuck direct-execution rows (follow-up to #1829) #1836

Follow-up to #1829 (task T5 in its plan).

#1829 makes an AWS direct RI exchange whose outcome is unknown (the accept response was lost) or a stuck submitted block the same source RI in every path: direct execute, AUTO and approve. That's fail-safe. But there's no API to settle such a row once an operator has checked AWS, so today the only way to unblock the RI is a manual DBA step (runbooks/ri-exchange-direct-execution-settle.md).

Needed

• A list endpoint for unresolved direct executions (provider='aws' AND status IN ('submitted','unknown')), scoped to the caller's accounts. No API reads ri_exchange_direct_executions today, and the refusal deliberately hides the row ID (sec(api): RI exchange session approve still leaks missing (404) vs not-pending (409) to approve-own callers #1428).
• A resolve endpoint, analogous to POST /api/ri-exchange/resolve/<id> for history rows. An operator marks a row completed (AWS shows the exchange) or failed (it doesn't), with a note. Permission-gated and audited.
• Audit-rule question. Audit rows are currently never rewritten from unknown. Decide between resolution columns (resolved_status, resolved_by, resolved_at, note) via a migration, and allowing the status transition. Resolution columns preserve the original outcome; the runbook currently rewrites status in place as an interim.
• The same safety rules as the runbook SQL: settle a submitted row only after the 4-minute execution window plus margin (created_at < now() - interval '5 minutes'); never touch Azure rows; and confirm the row still blocks the guard until settled, and stops blocking after.
• Tests for both directions, plus openapi.

Owner decision D1 on #1829 accepted shipping the guard before this exists, with the runbook as the interim.