Resolve URL mapping names from the match rather than the request

[codeconsole]

Resolves captured URL mapping names from the match itself rather than from the dispatching
request, which lets collectControllerMappings stop rebuilding the parameter map for every
candidate mapping on every request.

Measured

Benchmark	before ns/op	after ns/op
ControllerMappingCollectionBenchmark.oneCandidate	385.9	219.9	−43%
ControllerMappingCollectionBenchmark.twoCandidates	599.8	282.9	−53%
ControllerMappingCollectionBenchmark.fourCandidates	1241.6	777.4	−37%
UrlMappingBenchmark.matchCachedHit	2.49	2.56	unchanged

collectControllerMappings runs in full on every request even when the URL mapping cache hits,
so this is on the always-on path. It still costs ~88x the cached match it wraps; what remains is
ControllerKey allocation, the controller map lookup and the sort.

Why it was slow

A mapping's controllerName / actionName / namespace could be a Closure that read
RequestContextHolder.currentRequestAttributes().getParams() — reaching for thread-local state to
read a value the mapping already held in its own params. To ask a candidate "which controller are
you?", the framework had to call webRequest.resetParams() and info.configure(webRequest) first,
per candidate, cloning the parameter map each time.

Those names now resolve from the match. configure() is still called for mappings whose names are
genuinely request-dependent.

Deliberately unchanged

action = { params.goHere } is a documented feature — those closures are meant to read the request,
and they still do, taking the old path.

Behaviour change

A request parameter no longer stands in for a token the URI does not capture. Under
"/$controller/$action?", /article?action=gallery now routes to the default action rather than
gallery; a query string could previously steer which action ran. params.action is still bound
either way. Documented as section 47 of the 8.0 upgrade guide and in the embedded-variables guide.

This required changing one existing assertion, in UrlMappingParameterTests.testNotEqual, which is
worth a reviewer's attention. That test originally asserted the mapping did not match
(b84ef59, GRAILS-2297); when it moved to UrlMappingsUnitTest the fall-through to the default
mapping made info non-null and a controllerName == 'foo' assertion was substituted — 'foo' being
a value seeded into the request params by the test itself, i.e. an artifact of the thread-local
resolution rather than the notEqual constraint the test is named for. It now asserts the value the
URI actually captured.

Notes

• Adds grails-web-benchmarks (opt-in, not part of build/check). The same module is added by
  Reduce per-request work, and rework hidden HTTP method and multipart handling #16149; if that lands first this rebases and drops that commit.
• UrlMappingInfo gains isNameResolutionRequestDependent() as a default method returning true,
  so third-party implementations keep current behaviour.

[codecov]

Codecov Report

❌ Patch coverage is 72.22222% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.1242%. Comparing base (e40cb27) to head (4691e25).
⚠️ Report is 59 commits behind head on 8.0.x.

Files with missing lines	Patch %	Lines
.../org/grails/web/mapping/DefaultUrlMappingInfo.java	33.3333%	0 Missing and 2 partials ⚠️
...grails/web/mapping/RuntimeConstraintEvaluator.java	66.6667%	2 Missing ⚠️
...main/groovy/grails/web/mapping/UrlMappingInfo.java	0.0000%	1 Missing ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16150        +/-   ##
==================================================
+ Coverage     54.1238%   54.1242%   +0.0004%     
- Complexity      20307      20317        +10     
==================================================
  Files            2107       2108         +1     
  Lines          101144     101158        +14     
  Branches        17921      17925         +4     
==================================================
+ Hits            54743      54751         +8     
- Misses          38595      38597         +2     
- Partials         7806       7810         +4     

Files with missing lines	Coverage Δ
...org/grails/web/mapping/AbstractUrlMappingInfo.java	80.8219% <100.0000%> (+1.7174%)	⬆️
...groovy/org/grails/web/mapping/RegexUrlMapping.java	67.0543% <100.0000%> (-0.1272%)	⬇️
...ing/mvc/AbstractGrailsControllerUrlMappings.groovy	60.1942% <100.0000%> (ø)
...main/groovy/grails/web/mapping/UrlMappingInfo.java	0.0000% <0.0000%> (ø)
.../org/grails/web/mapping/DefaultUrlMappingInfo.java	37.9032% <33.3333%> (-0.1133%)	⬇️
...grails/web/mapping/RuntimeConstraintEvaluator.java	66.6667% <66.6667%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[testlens-app]

✅ All tests passed ✅

⚠️ TestLens detected flakiness ⚠️

Test Summary

CI - Groovy Joint Validation Build / Build Grails with Groovy snapshot (shard 2) > :grails-test-examples-scaffolding:integrationTest

Test	Runs	Flakiness
UserControllerSpec > User list	❌ 🚫 🚫 ✅	2% 🟡

🏷️ Commit: 4691e25
▶️ Tests: 18273 executed
⚪️ Checks: 90/90 completed

---

Learn more about TestLens at testlens.app/docs.

[codeconsole]

Consolidated into #16149, which now covers the request path as one reviewable change — per-request work, hidden HTTP method handling and multipart together.

This branch was merged in with its history intact; no commits were squashed or dropped, and git merge-base --is-ancestor confirms every commit here is contained in #16149.

Closing in favour of that. The reason is review flow rather than anything wrong here: these branches collided in GrailsDispatcherServlet.checkMultipart and UrlMappingsHandlerMapping, so reviewing them separately meant tracking a merge order, which is not a reasonable thing to ask of a reviewer.