fix: subject-bind client-supplied session ids in the resolver

[araujof]

Summary

Tiers 0 (agent.session_id) and 1 (JWT session_id claim) of the session resolver previously returned client/upstream-supplied session values raw. Because those values are attacker-chosen, one principal could supply another principal's session id and land in their session bucket — letting taint/state cross principal boundaries (security review Finding 2).

This change binds those values to the authenticated subject before use: the store key becomes sha256(subject_id : raw)[:16] instead of the raw value.

Changes

• Added short_hash() — shared 64-bit hashing helper so all derived session ids use one keying scheme (matches the Python hexdigest()[:16]).
• Added subject_scoped() — binds a client/upstream value to the authenticated subject; returns None when no subject is present (a bare client value has no safe scope, consistent with the identity tier).
• Tier 0 and Tier 1 now subject-bind their values and fall through when no subject is present.
• Refactored Tier 2 (identity) to reuse short_hash().
• Updated module docs to describe the subject-binding behavior.

Tests

• Client session id is hashed with the subject, never returned raw.
• Same session id under different subjects produces distinct keys (core Finding 2 guarantee).
• Same subject + same session id is stable across requests.
• A client session id with no authenticated subject falls through.

[terylt]

LGTM. Nice work. I added a few more tests.