fix: authenticate route-affinity metadata and bound multipart forwarding

[chubes4]

Found during merge-gate review of #135.

Problem

Route-affinity consumers can trust caller-supplied verified/client/remote-address metadata, allowing throttle identity spoofing. Multipart forwarding also hashes/loads files before public admission and does not preserve authenticated cookie/bearer identity like the standard cross-site helper.

Scope

• Replace public-header trust with server-verifiable affinity metadata tied to the forwarded request and target.
• Never preserve caller-supplied _ec_affinity_* identity fields.
• Preserve canonical authenticated identity for JSON and multipart forwarding without forwarding arbitrary user IDs.
• Enforce file count/per-file/aggregate bounds before hashing or loopback forwarding.
• Provide streaming/bounded multipart construction rather than unbounded memory concatenation where supported.
• Make public-write rate limiting concurrency-safe through the existing shared admission primitive.

Acceptance

Direct target-host spoofing, rotated client IDs, authenticated multipart, source-to-target JSON/multipart, concurrent limits, and oversized invalid-Turnstile requests are tested.