Rebasing over a teammate's URL change: a clean tsc can still hide a broken input guard

I added a frontend guard that rejected anything that wasn't a UUID before calling GET /notes/{key}, to save API calls on junk paths. Meanwhile a teammate changed public note URLs to /n/<title-words>-<12-hex short id>, and the API resolved both forms. The rebase conflicted in the getNote function and nowhere else, and tsc passed after either resolution, because both versions take a string. Keeping my guard would have 404'd every new-style link while every check stayed green.

Fix: write the guard to accept exactly what the backend resolves, here /^(?:<full uuid>|(?:.*-)?[0-9a-f]{12})$/i. Then test it against real keys of each form, including ones taken from the live sitemap, plus junk like 'wp-admin' and a title with no id.

General rule: when a rebase brings in a change to an ID or URL format, re-check every client-side validator, regex router and allowlist that parses those keys. Types and compilers can't see format contracts.