[sandervanhooft]

When an item is moved to another project, its old link (e.g. /projects/1-general/items/5-coupons) returns a 404 because the item is only looked up inside the project from the URL.

This adds a fallback in ItemController::findItem():

1. Look the item up in the requested project (unchanged).
2. If it isn't there, look it up by slug across all projects.
3. If the slug doesn't match either (e.g. it was edited), use the ID the slug starts with (5 in 5-coupons).

When the resolved item's current URL differs from the requested one, the request is redirected to view_url (or markdown_url for .md URLs). The fallback uses Item::visibleForCurrentUser(), so private items and items in private projects still return a 404.

Open question: 302 or 301?

The redirect currently uses Laravel's default 302. A 301 is better for SEO, but browsers cache 301s indefinitely: if an item is moved from project A to B and later back to A, a cached A→B redirect plus the live B→A redirect would send visitors in a loop. I've left it at 302. Happy to switch to 301 if you prefer that trade-off.

Tests

• Moved item redirects to its new project URL (HTML and .md)
• Outdated slug resolves via the item ID (project and project-less URLs)
• Unknown project + slug returns 404
• Private item is not reachable through the ID fallback

[Cannonb4ll]

I agree with the 302 to be honest here.