fix(ri-exchange): bound the direct execute's claim and AWS call by one deadline taken before the audit save #1840

Found in the plan review for #1836. This is live on main since #1838.

Problem. For a direct AWS RI exchange, the audit row's created_at is taken under the spend lock in SaveRIExchangeDirectExecution. After that:

• beginDirectExchange runs claimExchangeSubmit on the request context (internal/api/ri_exchange_audit.go:61);
• only then does the 4-minute execution budget start, as a fresh ctxutil.DetachedWithTimeout (internal/ctxutil/detached.go:17-19).

In HTTP-server mode the request context has no deadline: ReadTimeout/WriteTimeout at internal/server/http.go:74-75 don't cancel it, and the pgx pool has no acquire timeout. So with an exhausted pool, the claim can wait without bound, and the AWS accept can be sent at created_at + wait + 4 minutes.

Impact. The settle runbook (runbooks/ri-exchange-direct-execution-settle.md) treats a submitted row older than 5 minutes as no longer in flight. With a long claim wait, an operator following it could mark failed a row whose accept hasn't been sent yet. That releases the source RI while the exchange may still go through, which is a possible double exchange. Normally the wait is milliseconds, so the likelihood is low; but the bound the runbook relies on isn't enforced, and a longer age doesn't remove the gap.

Fix.

• Take one deadline before Save: deadline := time.Now().Add(riExchangeExecutionTimeout).
• Bound the claim with it.
• Run the exec with ctxutil.DetachedWithDeadline(ctx, deadline) (detached.go:27), so the accept can never start later than about created_at + 4 minutes, plus app-to-DB clock skew.
• Test: a slow claim shortens the exec budget, and a claim that outlives the deadline never reaches the executor.

Separately, owner decision Q2 for #1836 raises the runbook's submitted age from 5 to 10 minutes. That ships with this fix.