fix(backend): keep TLS fingerprinting when a request carries Next.js metadata

[HouMinXi]

Summary

• isTlsRequestEligible requires every option key to be on an allow list. RequestInit.next is Next.js cache metadata and was not on the list, so any request carrying it silently fell back to a plain fetch and skipped TLS fingerprinting.
• next is now allowed. It is not forwarded to the upstream transport. Any other unrecognized key still bypasses fingerprinting.

Related Issues

• Closes fix(backend): RequestInit.next silently disables TLS fingerprint eligibility #15320

Validation

• Change type: other (TLS fingerprint eligibility)
• Focused tests: node --import tsx/esm --test tests/unit/tls-proxy-context.test.ts (30 pass)
• eslint on the changed files, with the repo suppression file
• Reconciled with release/v3.8.52 @ 23a1148486
• Updated test covers the change
• Defect injection: removing next: true turns the new assertion red with 0 !== 1, and the change was restored

Tests Added Or Updated

• tests/unit/tls-proxy-context.test.ts (updated)

Coverage Notes

• One case carries next and asserts the request still takes the TLS path and that next is not forwarded. A second case carries an unrecognized key and asserts it still bypasses TLS.

Reviewer Notes

• The allow list gained exactly one key. The direct and the proxied paths share isTlsRequestEligible, so both are covered by the same change.