Revert back to v4 behavior for group registering implicit 404 handler…

[aldas]

FIX: #2950

Revert back to v4 behavior for group registering implicit 404 handlers. This will fix: CORS middleware doesnt automatically handle OPTIONS routes for groups anymore since upgrade to v5.

This is a breaking change in v5. It reverts back to v4 behavior.

[codecov]

Codecov Report

❌ Patch coverage is 90.47619% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.20%. Comparing base (01b45be) to head (662f4d0).
⚠️ Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
router.go	71.42%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2996      +/-   ##
==========================================
+ Coverage   93.17%   93.20%   +0.02%     
==========================================
  Files          43       43              
  Lines        4501     4517      +16     
==========================================
+ Hits         4194     4210      +16     
- Misses        189      190       +1     
+ Partials      118      117       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vishr]

Did a due-diligence pass on this PR in the context of the v5 group/CORS regression (#2950, and the related #2485/#2517). Notes for whoever reviews:

Approach looks right. Registering the catch-all with a nil handler (so the router picks the default/custom root 404) means this fixes both the CORS-on-group preflight case and custom-404 inheritance in one change — nice. The noAutoRegisterRoutes flag (default off ⇒ v4-compatible behavior restored by default) is the least-surprise choice for upgraders, and TestGroup_withoutRouteWillExecuteMiddleware covers the default path.

CI is effectively green. All test jobs pass (ubuntu/macos/windows × Go 1.25/1.26, check, benchmark). The only red mark is codecov/patch (90.47% vs 93.17% target) — a coverage threshold on the new lines, not a failure. A couple more assertions would clear it.

One thing worth gating the merge on: v5 removed the implicit group catch-all deliberately, because it could let 404 mask 405 Method Not Allowed and let a group's /* shadow other routes. This PR turns it back on by default and pairs it with AllowOverwritingRoute: true + router changes to compensate. Before merging, it'd be good to have explicit regression tests confirming those original failure modes stay fixed — e.g.:

• wrong method on a group route returns 405, not 404;
• a group catch-all does not shadow a sibling concrete route or a root-level route.

If those hold, this looks like the fix to close the loudest v5-upgrade complaint. Happy to help add the regression tests or a migration-guide note (the behavior change still isn't documented in API_CHANGES_V5.md).

[vishr]

Followed up on my earlier note with actual tests, and found one concrete thing worth a decision before merge: this PR reintroduces v4's 405-masking.

I ran the same scenario (POST to a GET-only route under a group that has middleware) across three branches:

Branch	POST /api/users
master (v5 today)	405 + Allow: OPTIONS, GET
v4	404, no Allow
this PR	404, no Allow

So the behavior change is faithful to v4 — but it's a regression relative to current v5, which correctly returns 405. Mechanism: the restored group catch-all (/api, /api/*) matches any method, so a method-mismatch on an existing path is intercepted as 404 instead of falling through to the 405 path.

Good news from the same test pass: the route-shadowing concerns I raised earlier are unfounded — concrete sibling routes, root-level routes, and sibling groups all still resolve correctly with the catch-all in place. The 405 case is the only regression.

I opened #3003 with these as regression tests (4 of them; all green on master). The 405 one fails against this branch — intentionally, to pin down the tradeoff. Two ways forward:

1. Preserve 405: only let the catch-all handle genuinely-unmatched paths, while method-mismatches on an existing path still return 405. Keeps both the CORS fix and v5's correct 405 handling.
2. Accept the v4 behavior consciously and document it (and adjust the 405 expectation in test: lock in v5 group route method-handling (405 + OPTIONS) #3003).

Happy to help with either. Leaning toward (1) if the router can distinguish the two cases.