Align backup, agent-limit, and offering claims with what runs

[jfrench9]

Four claims the platform made and did not keep, each aligned to what actually runs. Based on chore/stale-claims-cleanup (#952); retarget-safe once that merges.

Deprovisioning backup hosting: 90 days for everyone

The config promised 90/180/365-day post-cancellation backup hosting by tier. The S3 lifecycle rule (ExpireGraphBackups: 90) deletes the object at 90 days regardless, and the final deprovisioning backup creates no GraphBackup row, so the tier-aware cleanup job cannot see it to extend anything. Large and XLarge's extended hosting physically never happened. All tiers now promise the 90 days the infrastructure delivers, pinned by a test against the lifecycle ceiling. (Delivering more for real means exempting final backups from the lifecycle rule and tracking them — noted in the config for whoever builds it.)

Backup retention: capped at 90, clamped visibly

retention_days accepted up to 2555 days while the same lifecycle rule destroyed the object at 90 — producing COMPLETED backup records pointing at deleted objects, with restore failing opaquely. Three changes:

• The request field caps at le=90, with a description that says why.
• The per-tier clamp (7/30/90) now applies unconditionally — it previously skipped entirely when the graph row or tier was missing, which is exactly when clamping matters most.
• The clamp is visible: the operation envelope reports the effective retention_days and the message says when it was capped. The UI defaults the field to 90; a Standard customer was silently given 7 with no indication in the response or the backup list.

agent_calls_* limits: enforced for the first time

Repository plans have always advertised per-plan agent volume limits (agent_calls_per_hour etc. in /v1/offering), but nothing ever passed operation="agent" to the volume limiter — query/mcp/search each had their enforcement hook, the operator surface had none. All three operator entry points (auto, specific, batch) now run shared-repository access + agent volume limits through the same helper the other three surfaces use.

Offering copy: per-user repositories, one RAM number

• /v1/offering described repository subscriptions as per_organization ("all organization members share access"). Access, credits, and volume limits all key on the subscribing user (UserRepository / UserRepositoryCredits) — the copy now says per_user.
• The same tier claimed "4 GB RAM" in /offering and "3GB RAM" in /v1/graphs/tiers — the latter reported the LadybugDB memory budget, not the machine. Both now advertise instance RAM, and the memory_mb field description stops calling the instance-wide budget "memory allocated to your graph".

Testing

Full suite: 11,426 passed; only failures are the two pre-existing test_incremental_materialize cases that reproduce on main. New tests pin the hosting-days ceiling, the 90-day request cap (updating the test that pinned 2555), the agent-operation delegation, and the per-user pricing model.