optimize checkArnMatch: equality fast-path and memoized matchers

[delthas]

checkArnMatch built six RegExp objects per call (regex-escape + compile for the relative-id and each of the five ARN segments), for every (request context × policy statement × Resource entry). A V8 profile of Vault under warm authorization load showed this as the worker's dominant CPU cost (StringPrototypeReplace + RegExpConstructor + StringPrototypeSplit under evaluatePolicy, plus the resulting GC churn).

Two commits:

1. Equality fast-path — a wildcard-free portion translates to a fully-escaped, anchored regExp, so testing it is equivalent to string equality: compare those portions directly and only build a RegExp for portions containing *, ? or ${.
2. Matcher memoization — compiled matchers are pure functions of (caseSensitive, policyArn); cache them in a 10000-entry LRUCache. No invalidation needed; the LRU cap bounds the cardinality introduced by policy-variable substitution; a miss costs what every call cost before.

Behavior-preserving: verified by differential testing against the previous implementation over a matrix of literal/wildcard patterns, case-insensitive mode, policy-variable literals (${*}), empty-account service ARNs, and malformed ARNs — zero differences. Measured on a 1000-account Vault authz benchmark (warm, drift-controlled A→B→A): +18–19% throughput, p95 −16%.

Issue: ARSN-590

[bert-e]

Hello delthas,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request TBA
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• 2 peers

[claude]

LGTM

The equality fast-path correctly skips RegExp construction for wildcard-free portions, and the memoization via LRUCache is safe (non-global regexes, no statefulness, correct cache key partitioning by case-sensitivity). Case-insensitive handling for segments matches the prior behavior (only the relativeId is lowercased, not the five ARN segments — consistent with their standardized casing in practice). The hasWildcards guard conservatively routes any ${ through the regex path, preserving correct handling of ${*}, ${?}, and ${$}. Tests cover literal matching, wildcard matching, ${ escapes, utapi empty-account exemption, memoization consistency, and cache eviction — good coverage of the optimization invariants.

Review by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.95%. Comparing base (6a5ee64) to head (1078a4c).

Additional details and impacted files

@@                 Coverage Diff                 @@
##           development/8.4    #2637      +/-   ##
===================================================
+ Coverage            73.92%   73.95%   +0.03%     
===================================================
  Files                  229      229              
  Lines                18480    18509      +29     
  Branches              3822     3836      +14     
===================================================
+ Hits                 13661    13688      +27     
- Misses                4814     4816       +2     
  Partials                 5        5              

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.