fix(f/M4,M1,M7): wire the link lookup; stop blaming Clio for our 429s; treat 404 as gone

Three reviewer items that land in the same files.

(f/M4) GET /clio-matters/links/:projectId now exists, using the getLinkForProject
export that was dead code. Registered in the literal-path block ahead of the
/:matterId routes - declared after them, "links" would be swallowed as a matter
id (asserted by a test). Uuid-guarded in the route as well as the seam, and one
uniform 404 for every kind of "no" (absent / not visible / malformed /
unmigrated) so the endpoint cannot be used to probe which workspaces exist. The
Workspaces-tab badge that would consume it stays deferred.

(M1) A 429 can come from our own per-user bucket, but the server called it "Too
many Clio requests" and the client overwrote it with "Clio is rate-limiting
requests" - both blaming Clio for a limit JessicaOS imposed. The server detail
is now neutral, and the surfaces show the server's own message on 429 with a
neutral fallback, so a real Clio 429 and ours stay distinguishable.

(M7) A 404 on save or delete means the entry is already gone from Clio (deleted
in another window), which makes the list on screen stale - so 404 joins 409/412
in offering "Reload time entries", and a 404 delete drops the row rather than
leaving a ghost the solicitor can retry forever.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>