feat: versioned objects and migrations for syft-client

[bitsofsteve]

Versioned objects for syft-client with migrations, plus peer protocol-schema exchange wired into JobStorage and DatasetStorage.

• VersionInfo (SYFT_version.json): V1 + V2. V2 advertises slim protocol schemas for syft-client/syft-job/syft-dataset; first migrations (v1<->v2).
• ProposedFileChangesMessage (msgv2) and FileChangeEventsMessage: envelopes are the migratable units; items stay unregistered so checkpoint/cache payloads are unchanged.
• Protocol 0 = releases <= 0.1.117 (no identity fields); reads upgrade in memory via shims at the existing choke points. Old clients ignore the new keys (verified against the 0.1.117 models).
• Release discipline: history artifacts for 0.1.117, export script with bump/frozen-once guards, blob fixtures + p2p compat tests.
• PeerManager.live_peer_schemas(protocol) feeds live peer schemas into JobStorage/DatasetStorage: jobs negotiate per peer, datasets per audience. Also fixes peer_schemas or {} dropping the shared reference in both storages.

Out of scope: checkpoints, Peer/SYFT_peers.json, local caches, the semver handshake (unchanged).

One wave per commit; green at every commit.

[pjwerneck]

No major issues found. Excellent PR.

Some high-level concerns:

• The PeerManager - storage coupling via a shared mutable dict is fragile, and apparently already caused a bug fixed in this PR (the peer_schemas or {} check). The assumption that the dict must not be copied is an unwritten contract easy to overlook.
• Every peer of every version must be capable of parsing every future version file, and VersionInfo says changes must be additive-only, but there's nothing enforcing that. It's a convention that everything new must be optional, but there's nothing preventing someone from adding a VersionInfoV3 with a new required field, breaking old readers. I'd add a hard check, like a __init_subclass__ method that verifies new VersionInfo subclasses on creation.