fix(rbac): compile endpoint patterns once at load, not per rule per request (#3979)

[akshat-kumar-singhal]

Stacked on #3934. The racy call sits in code that PR rewrites, so this branch is built on top of it.
Only the last commit — fix(rbac): compile endpoint patterns once at load, not per rule per request — is
under review here; the rest belong to #3934 and will disappear from this diff once it merges.

Description:

Fixes items 1 and 2 of #3979: the RBAC matcher's data race, its unbounded router growth, and its
per-request allocation cost. Item 3 of that issue (multi-role JWT claim arrays) is independent and
needs a semantics decision first, so it is left for a separate PR.

matchMuxPattern built a route per rule, per request, on the Config's shared muxRouter:

route := router.NewRoute().Path(pattern)

mux.Router.NewRoute appends to the router it is called on (mux@v1.8.1/mux.go:279-284), and
config.muxRouter is created once at load and shared by every request. So each pattern test both
mutated shared state without synchronization and left its entry behind permanently.

Each pattern is now compiled once at load, onto a router of its own, and stored on endpointRule.
Route.Match only reads the route and writes into the caller's RouteMatch, so a route that is never
written to again is safe to share across goroutines. The shared muxRouter is gone.

A per-scan matchContext carries the request and a single reused RouteMatch. Without it one
RouteMatch escaped per rule scanned, so cost still grew with config size.

This does not change which requests match which rules. #3979 suggests reading
mux.CurrentRoute(r).GetPathTemplate() instead. That works, but it compares config paths against
registered route templates rather than request paths — the breaking change #3935 defers to its own
item 3 and argues should not be the default, since a rule like /admin/{path:.*} deliberately spans
many registered routes today. That belongs in #3935 on its own merits, not smuggled into a bug fix.

Root cause analysis:

• Symptom. Under concurrency, -race reports a race on mux.(*Router).NewRoute reached through
  rbac.matchMuxPattern. Separately, a long-lived process accumulates router entries without bound
  (0 → 114 routes after 100 requests, per RBAC: per-request pattern matching races and grows the router without bound; multi-role JWTs authorize nothing #3979), and authorizing one request costs hundreds to
  thousands of allocations, on the hot path of every route in the application.
• Root cause. Config is documented as read-only after initialization — getExactEndpoint and
  GetEndpointPermission both carry the comment "Config is read-only after initialization, so no mutex
  is needed." matchMuxPattern broke that invariant: NewRoute is a mutating call, and it was being
  made on a shared field on every request. The pattern compilation it performed is fully determined by
  the config, so it never needed to happen at request time at all.
• Why it wasn't caught. The existing suites drive requests sequentially, and the package had no
  -race concurrency test and no benchmark. A sequential test cannot observe either failure: the race
  needs two goroutines, and the growth is invisible without counting routes or allocations.
• Fix. Compile at load onto a per-pattern router; store the compiled *mux.Route on the rule; reuse
  one RouteMatch per scan. matchesHTTPMethod is deleted — endpointRule.matchesMethod was its only
  caller and allocated a one-element slice per rule per request to reach it, and its list handling is
  unreachable now that buildEndpointRules expands methods into one rule each.
• Prevention. Three regression tests added, described below. The concurrency tests fail on the base
  branch with exactly the stack RBAC: per-request pattern matching races and grows the router without bound; multi-role JWTs authorize nothing #3979 reported.

Verification:

TestConfig_resolve_concurrent and TestMiddleware_concurrent drive 50 goroutines × 20 requests
through the resolver and through the mounted middleware. Both fail -race on the base branch and pass
here; go test -race -count=2 ./pkg/gofr/rbac/ is clean.

BenchmarkConfig_resolve (Apple M4), before → after:

rules in config	before	after
6	36,730 ns/op, 1,064 allocs/op	927 ns/op, 6 allocs/op
21	131,730 ns/op, 3,924 allocs/op	1,026 ns/op, 6 allocs/op
51	373,669 ns/op, 9,684 allocs/op	1,717 ns/op, 6 allocs/op

TestConfig_resolve_allocations guards that flatness. It compares a small config against larger ones
rather than asserting an absolute count: the race detector adds three allocations, so a bound tuned
without -race fails CI with it and one tuned for -race is slack. The property the fix establishes
is that per-request cost does not scale with rule count, so that is what the test measures.

Package coverage is 94.3%.

Breaking Changes (if applicable):

None. Matching semantics are unchanged, and no exported API is touched — muxRouter,
matchMuxPattern, matchesEndpointPattern and matchesHTTPMethod are all unexported.

Additional Information:

No new dependencies. endpoint_matcher_test.go shrinks because TestMatchesHTTPMethod is removed with
the function it covered (superseded by TestEndpointRule_matchesMethod) and TestMatchMuxPattern is
retargeted at compilePattern as TestCompilePattern, which also gains cases for literal paths,
empty paths and patterns mux cannot compile.

Three pre-existing noctx lint findings remain in endpoint_matcher_test.go (httptest.NewRequest
rather than NewRequestWithContext). They are present on development, untouched here, and part of the
mechanical golangci-lint backlog.

Checklist:

• I have formatted my code using goimport and golangci-lint.
• All new code is covered by unit tests.
• This PR does not decrease the overall code coverage.
• I have reviewed the code comments and documentation for clarity.