[Performance] Benchmark and bound security-critical token parsing before optimization

[seonghobae]

Buyer-visible problem

Artifact-link verification and tenant-claim parsing are request-path security boundaries. A parser rewrite that merely appears allocation-efficient can increase complexity, shift denial-of-service work before structural validation, or change malformed-input semantics without producing a material latency or allocation improvement.

Required evidence before a parser optimization PR

1. Add a reviewable JMH or equivalent forked-JVM benchmark on the repository's supported JDK 21 runtime.
2. Compare the current implementation and each candidate using identical valid and hostile corpora:
   • normal signed artifact tokens;
   • missing, extra, leading, trailing, and repeated delimiters;
   • invalid signatures;
   • maximum supported token length;
   • comma-separated permission sets with empty, duplicate, whitespace, and maximum-cardinality entries.
3. Record at least ns/op, B/op, allocation count, warmup/fork configuration, CPU/JVM identity, and variance.
4. Add explicit request limits for token/header length and permission cardinality before expensive HMAC or substring work where those limits are not already enforced.
5. Prove byte-for-byte/exception-status behavioral equivalence with property tests and existing fuzz corpora.
6. Preserve production statement and branch coverage at 100%, public API docstrings, Security Scan, SAST, and fuzz.
7. Require a material, predeclared threshold, such as at least 15% lower allocation with no statistically meaningful throughput regression. Do not merge a manual parser solely because unit tests pass.

Scope

This issue supersedes speculative PR #442's measurement claim. It does not assume that split/Stream or a manual loop is faster; the benchmark determines the decision. Generated task-description files are not production evidence and should not be committed as part of the implementation.