Cache Cost Explorer responses locally (1h TTL) — avoid $0.01/req billing burn

Context

cost:analyze calls ce:GetCostAndUsage. AWS charges $0.01 per Cost Explorer API request. Running the command in a tight loop, scripted, or as part of a regular reporting cron would silently rack up its own line item on the bill.

There's no caching today — every invocation hits AWS.

Proposal

Local response cache for Cost Explorer queries:

• Key: (profile, start, end, granularity, groupBy, metrics) — anything that affects the response shape.
• TTL: 1 hour (configurable, sensible default). Cost data for closed months never changes, so for a query on a fully-closed period the TTL could be effectively infinite — worth handling that too.
• Storage: filesystem cache under ~/.cache/ts-cloud/cost-explorer/ (or whatever XDG-style location matches our convention). Per-profile subdirs to avoid cross-account contamination.
• Invalidation: --no-cache flag to bypass; cost:cache:clear (or similar) to wipe.
• Visibility: when a cached response is used, print a one-line (cached, NNN seconds old) so the user knows.

Acceptance

• Running cost:analyze twice in a row with the same params hits AWS once.
• Cached responses survive across separate invocations of the CLI (filesystem-backed, not in-process).
• --no-cache actually skips both read and write of the cache.
• TTL is enforced — past TTL, cache is invalidated and a fresh request is made.
• Cache key includes the profile so --profile a and --profile b don't share an entry.
• Closed-month data (start + end both before the current month) gets a longer effective TTL (or never expires — closed months are immutable in Cost Explorer).
• Documented in the README / cost.md once that lands.

Why now

This was deferred from the original #104 scope. With cost:analyze actually shipping and being used (Glenn ran it twice during triage today already), the burn is real.

Related

• #104 — original cost-reporting CLI issue (deferred this from scope to ship the core ranking faster).