feat(handlers): record subject_digest and plumb through store

What

Records the OCI subject digest on push and threads subject_digest through the datastore, so the manifest triggers (added in !2930 (merged), now in master) can link a referrer's subject_id regardless of the order in which the referrer and its subject are pushed (#2376, the handling half of the split-out from !2929 (closed)). Until this lands, subject_digest is never written, so those triggers are inert; this MR is what activates them.

• Write path (registry/handlers/manifests.go): set subject_digest from the manifest's subject on every push. It only ends up stored with a null subject_id when REGISTRY_FF_TOLERATE_MISSING_SUBJECT is enabled (tolerance landed in !2927 (merged); the flag is still off by default in production).
• Plumbing: subject_digest through models.Manifest, the manifest INSERTs, the row scanners, and the manifest SELECT column lists. Read paths (referrers listing, GC IsDangling) are unchanged; they keep using subject_id, now kept correct by the triggers.
• Tests: datastore integration tests covering both push orderings.
  • TestManifestStore_SubjectIDBackfilledOnSubjectCreate: a referrer created before its subject (null subject_id, recorded subject_digest) is linked by the AFTER INSERT trigger when the subject is created.
  • TestManifestStore_SubjectIDResolvedWhenSubjectExists: a referrer created after its subject, with a null subject_id, is linked by the BEFORE INSERT trigger at insert time (the deterministic ordering the AFTER INSERT backfill alone does not cover).
  • Both also assert online GC IsDangling: a linked subject is protected from collection, while an untagged, otherwise-unreferenced referrer is collectable.

Notes

• Last of the split-out MRs. The column (!2928 (merged)), the triggers and index (!2930 (merged)), and the tolerance flag (!2927 (merged)) are all merged; this targets master directly.
• After this merges, the remaining work in #2376 is operational, not code: flip REGISTRY_FF_TOLERATE_MISSING_SUBJECT on (a separate rollout), then eventually remove it.
• Known residual: a truly simultaneous referrer-and-subject push, where both transactions are still uncommitted when each runs its trigger, can leave a referrer with a null subject_id. It is acceptable while the flag is off and needs read-time resolution or a reconciliation sweep before the flag is enabled. Tracked in #2376.

Part of #2376.