Verifier: google_1p_code only checks the pre-March log, and cache cleanup never deletes #19

google_1p_code fails every entry in the current log. The target in cmd/verifier/verifier.go points only at developers.google.com/android/binary_transparency/google1p, whose checkpoint has been at size 134 since 2026-03-30. The README lists https://www.gstatic.com/android/binary_transparency/google1p/jwt/2026/01/ as the latest shard. It's at 226 entries with none shared with the old log (192 Messages, 20 as.oss, 7 contactkeys, 7 safetycore). For example, this payload returns FAILURE: payload not verified in any log:

4bc401f3273c355a06b44cf4c0fc91e2943b8cb9b8685f0f2fda1eb409b4d7c5
SHA256(Signed Code Transparency JWT)
com.google.android.apps.messaging
322660063

It verifies after three changes: add gstatic.com/android/binary_transparency/google1p/jwt/0 to the origins in internal/checkpoint/checkpoint.go, add a target for the new base URL with the same key under that name, and use tileHeight: 8 for it (1 gets a 404 on tile/1/7/000.p/1). Keeping the old log as a fallback target, the way google_1p_apk does, would cover both. The google1p log_details page also still points at the old checkpoint and package_info.txt.

Cache cleanup never removes anything. In internal/tiles/reader.go:264 the loop lists targetDir but builds the path to remove as filepath.Join(abtCacheDir, entry.Name()), so os.Remove targets a file that doesn't exist. I put an image_info.txt_1000 dated January into <cache>/pixel/, ran --log_type=pixel to download image_info.txt_1109, and the old file was still there. For google_1p_apk each change in the 2026/01 tree size leaves another 210 MB package_info.txt_<size> behind.

Smaller: the 30 second Timeout on httpClient (reader.go:123) covers reading the body, so fetching the 210 MB package_info.txt needs about 56 Mbps. It failed with context deadline exceeded here while another download shared the link, and passed in 11 seconds without one.