feat(cryptify): move the upload limits and rolling window into config, and serve the default tier's on GET /limits

[dobby-coder]

Closes #386.

Five config keys

per_upload_limit, rolling_limit, api_key_per_upload_limit,
api_key_rolling_limit and rolling_window_days are optional on
RawCryptifyConfig and resolved on CryptifyConfig, following chunk_size.
They default to 5 GB / 5 GB / 100 GB / 100 GB / 14 days, which is what the five
consts in store.rs held, so no deployment changes behaviour. Those consts are
gone.

The window is configured in days. CryptifyConfig carries both
rolling_window_days() and rolling_window_secs(), and the doc comment on the
field records what the ticket asked it to: changing the window reinterprets
usage already recorded, which changing a byte limit never does.

Every reader goes through an accessor

The per-upload branch, the rolling branch, the {}-day in the rolling 413's
message, and GET /usage, which held its own copy of the API-key tier's numbers
independently of both branches. That third authority is most of why the ticket
exists; usage now takes &State<CryptifyConfig> like everything else.

The window reaches the store through Store::with_idle_ttl, which grows a
rolling_window_secs: i64 parameter, and on to StateDb and prune_records.
store.rs takes the value and never fetches it: no config is read there.

GET /limits

Unauthenticated, mounted in api_routes() and added to api-description.yaml.

{"per_upload_limit_bytes":5000000000,"rolling_limit_bytes":5000000000,"window_days":14}

Default tier only. No guard, no Option<ValidatedApiKey>, nothing per-tenant,
so there is no path by which the body could vary with Authorization. It
inherits the global CORS fairing and needs no preflight. rolling_limit_bytes
is deliberately not /usage's limit_bytes, since the two report different
tiers.

Tests

served_per_upload_limit_is_the_enforced_one and
served_rolling_limit_is_the_enforced_one read /limits unauthenticated, drive
an upload past each cap, and assert the 413's limit_bytes equals what was just
served. The two numbers are compared against each other, not against a literal.

limits_are_byte_identical_for_every_caller compares the anonymous body against
one sent with an API key the mock pg-pkg really validates, checked by a 200 from
/usage with the same key first.

limits_serve_the_default_tier_only configures all four byte limits to distinct
values and pins both which pair is served and that the body has exactly three
keys.

a_configured_rolling_window_reaches_limits_and_the_store sets the window to 3
days and asserts /limits reports it and get_usage's oldest_expires_at
moves with it.

Five config tests, one per key: the default when the key is absent, the
configured value when it is set.

Test 3 shown red

As the acceptance check asks. Giving limits an ApiKey guard and returning
the API-key tier when a tenant resolves:

assertion `left == right` failed: /limits must not vary by Authorization, in status or in body
  left: (Status { code: 200 }, "{\"per_upload_limit_bytes\":5000000000,\"rolling_limit_bytes\":5000000000,\"window_days\":14}")
 right: (Status { code: 200 }, "{\"per_upload_limit_bytes\":100000000000,\"rolling_limit_bytes\":100000000000,\"window_days\":14}")

Restored afterwards. The committed tree is the one that passes.

Where the deleted consts' test readers get their number

Per the amendment on the issue. The store tests pass the window in as the new
parameter and compute their expectations from that same binding; the main.rs
test that asserted against ROLLING_LIMIT reads it off the CryptifyConfig its
figment already built. No test-local const. The tests that never mention the
window pass it at the call site rather than through a shared name.

One anchor in mod api_gate_tests had to move

narrow_a_response_property_type anchored on

                  window_days:
                    type: "integer"

which /limits now also matches, so once failed on a non-unique anchor: the
module's own trap firing as designed. The anchor is now USAGE_WINDOW_DAYS,
which takes in the per_upload_limit_bytes line that follows it in /usage.
Same mutation, same verdict.

Scope

cryptify/CLAUDE.md gained a line about where the numbers live now, since the
old one said the store prunes on a 14-day window and the store no longer knows.
Nothing else moved: not metrics.rs, not COMPATIBILITY.md, nothing under
.github/workflows/, not the website. The companion
website ticket in postguard-js is unblocked by this one.

Verification

cargo test -p cryptify (219 passed), cargo clippy -p cryptify --all-targets -- -D warnings, cargo fmt --check and cargo test --workspace are all green.
oasdiff is not installed in this container, so the gate's mutation test
skipped locally; its anchor assertions ran and pass.

🤖 Generated with Claude Code

Reviewed by dobby: the code-comments rule over the full diff (no breach — config.rs, store.rs and main.rs all comment at their files' measured rate), plus a correctness/design pass; 4 findings, all 4 fixed in cbad854, d6b1434 and 643249d — cargo test -p cryptify (220 passed), cargo test --workspace, cargo clippy -p cryptify --all-targets -- -D warnings and cargo fmt --check all green — approve.
Note: the Scope section above no longer says conf/config.toml is untouched; the five keys are documented there now, which is one of the four fixes.