Email operator surfaces sandbox refusal credential

Found while verifying the SES prod cutover (Task 9432) on https://app.jaah.ai: 1. **Delivery log / Send test, SES sandbox refusal.** In the sandbox, a send to an unverified recipient is shown verbatim as `AccessDeniedException … not authorized to perform 'ses:SendRawEmail' on resource …:identity/<recipient>`. That reads like a broken IAM grant. Recognise this shape and show "SES is in sandbox: the recipient is not verified. Production access is pending" (keep the raw reason in a details line). 2. **New credential form, Unsubscribe signing key type.** The NodeVault hint says "Jaah's servers refresh this credential's Connect tokens, so it can't use NodeVault", which is wrong for a signing key. Show the type's real reason instead: the CP itself verifies links signed with it. 3. **Automations list URL.** `/automations?when=event` ignores `when`, while a previous `q` search sticks after navigation. Read the When/Status/Owner filters from the URL, as `q` is read. Out of scope: changing SES behaviour, IAM, or the sandbox itself. Done means: each item is reproduced before the change and fixed after it on a local stack. A unit test covers the sandbox-reason mapping (1). Web tests cover (2) and (3). `./dc check quick` is green.

Fixed all 3 items. (1) SES sandbox refusal now shown in words, raw reason below. (2) Signing key gets its own NodeVault reason, form and migration report. (3) Automations reads When/Status/Owner from the URL. Quick gate green; PR #6809 queued in merge lane.