docs(specs): require the last_downloaded_at bump to be throttled

What

Adds a normative requirement to S16: the last_downloaded_at bump on a manifest GET/HEAD must be throttled inside a staleness window rather than unconditional, because the column is a key column of the retention index on both remote container tables, so every bump rewrites the row across every index a live row belongs to (six index entries on container_remote_manifests: the primary key plus five of the six indexes) on the hottest metadata path a pull-through cache serves.

The first commit's technical content is unchanged from what landed on !1354 (merged); it only relocates that content. That schema MR's reviewers are there for the DDL, and this requirement reaches an Approved spec and constrains the writer a later step ships, so per docs/dev/conventions.md and CLAUDE.md guardrail 4 it gets its own Spec MR.

The second commit is new. A Duo review on this MR flagged that the staleness window had no stated duration or config mechanism, so it adds last_downloaded_at_staleness_window (default 1h) to ContainerRemoteConfig, its startup-validation criterion, and reconciles the download-signals mapping table and the "A cached pull records a download" criterion so they agree with the "A repeat pull inside the staleness window writes nothing" criterion the first commit added.

Spec: docs/specs/S16-container-remote.md#download-signals. Plan: docs/plans/2026-07-30-container-remote.md (Step 11: cache-hit serve + download signals).