Announce spec shaking v3 and shake by the recorded version

[leighmcculloch]

Note

Part of a stack of PRs that must merge in this order.

A first group of PRs deliver const-encoded contract specs, so that contract specs are produced at compile time instead of at proc-macro execution time. This provides the foundation for the capability to construct the specs from information that is not known at proc-macro execution and only known at compile time, like the fully qualified name of a type:

1. Add borrowed View variants of types rs-stellar-xdr#560
2. Add const XDR serialization rs-stellar-xdr#562
3. Encode contract spec XDR at compile time rs-soroban-sdk#1965

A second group of PRs deliver fully qualified type names in contract specs. Instead of a type having the name Context it will have the name soroban_sdk::auth::Context. Qualified type names make it possible to uniquely identify types in the spec, even when they have the same name. This resolves several problems with contract specs the type identify problem (stellar/rs-soroban-sdk#1570), type aliases limitations (stellar/rs-soroban-sdk#1857 stellar/rs-soroban-sdk#1063), and optimise spec shaking data section size (stellar/rs-soroban-sdk#1978):

1. Widen contract spec type and event name limits stellar-xdr#312
2. Widen contract spec type and event name limits rs-stellar-xdr#566
3. Qualify type and event names rs-soroban-sdk#1970
4. Update stellar-xdr to 28.0.0 rs-stellar-rpc-client#108
5. Reduce qualified type and event names #2674

A third group of PRs use those qualified names to shake specs by reachability, so that the markers a contract carries shrink to the few entries a spec never names:

1. Shake specs by reachability and markers rs-soroban-sdk#2043
2. Announce spec shaking v3 and shake by the recorded version #2720 ← this PR

What

Patch in the soroban-sdk change that shakes specs by reachability (stellar/rs-soroban-sdk#2043), announce SOROBAN_SDK_BUILD_SYSTEM_SUPPORTS_SPEC_SHAKING_V3 to the SDK alongside the existing v2 var, and pick the shaking rules from the rssdk_spec_shaking version the built wasm records rather than from a single fixed set of rules.

Why

Each var names a set of shaking rules, and this CLI announces every set it can apply, because the SDK refuses to build a contract whose rules the build system has not claimed. The v3 var is required by that SDK: from that version most types carry no marker, and a build system has to shake them out by following the references to them instead, so one announcing only v2 would shake by markers alone and strip every type. The v2 var stays set because it is still true of this CLI, and a contract built against an older published SDK looks for that var alone and refuses to build without it.

Which rules apply to a given wasm is a property of that contract, not of the CLI — it may have been built long before this version — so the CLI reads the version the contract recorded and passes it to soroban_spec::shaking::filter: version 2 keeps an entry only if it carries a marker, version 3 also follows the references from functions, events, and types, and a wasm recording no version at all is left unshaken.

Known limitations

Contract fixtures built by the tests resolve soroban-sdk from crates.io rather than through the workspace patch, so they cover the version 2 path and the SDK's own end-to-end test contract covers version 3. The [patch.crates-io] git revisions are replaced with published versions once stellar/rs-stellar-xdr#566 and the soroban-sdk stack land and release.