Add DELETE /:code (permanently remove a short link)

There is currently no way to take a short link back once it's been created -- expiresAt is opt-in and set at creation time, but a link created without one lives forever, and there's no "oops, wrong URL" or "this campaign is over, kill the link" path at all. Anyone who creates a link pointing somewhere they later need to disable -- a leaked internal URL, a promo that ended, a typo they didn't catch -- has no way to stop it resolving short of going around the API entirely. That's a real gap for any service whose whole job is controlling where a link points.

DELETE /:code is registered as a stub in src/routes/redirect.js (right before module.exports). It compiles and the route exists, but its handler unconditionally throws -- hitting it always returns a 500, regardless of :code.

npm run dev curl -s -o /dev/null -w "%{http_code}\n" -X DELETE http://localhost:3003/1

-> 500 Internal Server Error

This is the one ticket in this set that isn't a single self-contained change -- it's a coordination problem across the two stores this project already keeps in sync everywhere else. Every other write path here (POST /shorten's write-through, the redirect handler's cache-aside populate-on-miss) is careful about keeping Postgres and Redis consistent; a delete has to be equally careful in the other direction. Deleting only the Postgres row and forgetting the cache means a window (up to CACHE_TTL_SECONDS) where the "deleted" link still redirects for anyone hitting a cache hit -- silently undermining the whole feature. There's also a not-found case to get right cleanly: Prisma's delete throws (a P2025 "record not found" error) if you try to delete a row that isn't there, rather than silently no-op'ing.

Add a deleteLink(shortCode) function to src/lib/linkService.js alongside createLink/findByShortCode (follow the same shape: takes a shortCode, does the Prisma call, returns something the route can check). In the route handler, after the delete succeeds, call invalidateCachedLink (already imported at the top of src/routes/redirect.js) before responding -- the ordering matters: the cache must be clear before you tell the client the delete is done, not after. Decide whether to check existence first (findByShortCode, already imported in this file) or let the delete itself fail and map that specific error to a 404 instead of letting it fall through to the generic 500 handler.