fix(checkpoint): cap the legacy prompt_attributions carry-forward

Metadata.LegacyPromptAttributions is dead data that every path re-emitting a session's metadata.json nonetheless copies into a fresh blob: each one decodes the whole Metadata and re-encodes it, so an oversized value an older CLI recorded is re-committed for the life of the session, whether or not the rewrite had anything to do with attribution.

It is also the one metadata field whose size scales with the working tree rather than with the session: CLI versions before v0.10.1 recorded every file of every nested git checkout on every prompt, producing the 70MB and 106MB metadata.json blobs that made entire/checkpoints/v1 unpushable to GitHub (100 MiB per-blob hard limit).

Cap it at 4 MiB and drop it past that. The git store had three separate session-metadata blob writes, so the cap goes in a new choke point, writeSessionMetadataBlob, that all three now route through rather than living at the one site that reads the field forward. fsstore gets the same cap in its own carry-forward.

Measured over this repo's v1 history, the largest prompt_attributions readable here is 1.73 MiB and only 11 of 11,929 metadata.json blobs exceed 64 KiB, so the cap clears every healthy record and fires only on the pathological shape. initial_attribution is left uncapped: one snapshot per session rather than one per prompt, largest value 254 bytes.