Share Tink primitives and fix concurrent cache invalidation

[script3r]

Fields using the same keyset built separate Tink primitives, and cached_property could publish an old primitive after clear_keyset_cache() returned during a concurrent first access.

Cache primitives alongside their shared keyset handle and synchronize construction/publication with invalidation. The shared cache remains bounded, and weak manager tracking allows fields to be collected. Calls that already obtained a primitive can finish with the old key; subsequent calls reload the replacement. Document the per-process boundary.

Validation: 4 new regression cases failed before the fix. All 109 library and 6 example tests pass on Python 3.14 / Django 6.0 and Python 3.10 / Django 5.2 / Tink 1.13.0. Tests exercise concurrent invalidation, actual key rotation retaining old decryption keys, bounded eviction, and garbage collection. Ruff lint/format and Pyright pass.

The included python -m benchmarks.keyset_cache microbenchmark measured 100 keyset-manager initializations at 2.227 ms before / 1.466 ms after, with primitive construction reduced from 100 calls to 1. Warm primitive access plus encryption measured 0.504 us before / 0.598 us after: synchronization has a small steady-state cost. These are local Python 3.14 measurements, not application throughput guarantees.

Stack position: 3 of 6; depends on #8. Land the lookup and datetime PRs first, then retarget to main as needed.

Landing order: #7 → #8 → #9 → #10 → #11 → #12.

Full review and landing notes. Use merge commits to preserve stack ancestry; squash/rebase merges require rebasing the remaining stack before landing it.