Cloud accounts: an operator panel that holds every provider key sealed, read-only first, and shows what each read was for #340

The owner wants to bring the keys to all of his cloud subscriptions (Cloudflare, DigitalOcean, AWS, Azure, Fly, Backblaze) into the forge and then let the crew optimize them safely. Trust comes from three things: the key is sealed and never shown again, the forge asks for the narrowest scope that does the job, and every use is a visible event.

Intent: one Settings → Cloud accounts page over the forge-level secrets table (#335): add a provider, paste a credential (write-only), and the forge immediately verifies it with a read-only call and says what the credential can do (account name, zones, projects) in one sentence.

Acceptance:

• [ ] providers: cloudflare, digitalocean, aws, azure, fly, backblaze — each with a verify call that lists accounts/zones/projects read-only and reports the token's own scope where the API exposes it
• [ ] a credential is stored through #335 at forge scope under <provider>/<name>; the page lists providers, names, last verified, last used by which run, never values
• [ ] every read by a run appears on the page and on the run page (provider, name, run, when)
• [ ] a read-only audit run per provider: idle resources, forgotten DNS records, unattached volumes, over-provisioned droplets, written up as one issue per finding with the saving estimated; nothing is changed by an audit
• [ ] a 'write allowed' switch per credential, off by default; a run that needs writes is refused while it is off and the refusal says so

Files: src/web/pages/settings.ts (new card), src/core/secret_store.ts (#335), src/crew/runner.ts (#336 injection), a small per-provider verify module. Depends on #335 and #336. Risk: a verify call on a write-capable key — verify endpoints must be reads only; list them in the module header.

Owner, 2026-10-02: widen this into accounts, the same primitive as model subscriptions — one shape for every third party the forge leans on: clouds (Cloudflare, Vercel, AWS, Azure, DigitalOcean, Fly, Backblaze) and services (Resend, Twilio, …). "There are things you just go with third party; that is the reality. Env secrets work; this is the next step. Start simple. Proper scope and planning."

Planner (Atlas): turn this into a linked plan, smallest useful first:

1. Account = a sealed credential + a provider + a scope (allow-list of orgs/repos, empty = none; the same rule as model subscriptions in #460), on the forge-level secrets table (#335). Verify on save with a read-only call that names what the key can do.
2. Spend: per provider, the month-to-date bill or usage where the API exposes it (Cloudflare, Vercel, AWS Cost Explorer, Azure Cost Management, DO balance, Twilio/Resend usage), on one page beside model spend; refreshed hourly; source and freshness stated.
3. Control panel, read-first: inventory per account (zones/DNS, projects/deployments, droplets/volumes, numbers/domains) in fleet-style tables (#445); writes only through reviewed changes.
4. Infrastructure as code, native: an app/repo can declare infra (OpenTofu) that the crew plans and a person applies, with the account credential injected per run (#336) and state in the forge's bucket; the tofu spike (#339) is the proving step.
5. Env bridge: an app's env secrets can reference an account (e.g. RESEND_API_KEY from account resend/main) instead of a pasted copy, so rotating the account rotates every app.

Keep each child to one run; link to #335, #336, #339, #445, #460.