Solidity version source: @custom:cdm @org/name:X.Y.Z

[charlesHetterich]

Since #76, cdm deploy publishes the exact X.Y.Z semver of each contract, sourced from Cargo.toml for Rust crates. Solidity contracts had no version source, so any Foundry/Hardhat deploy aborted — with an error telling the user to edit a Cargo.toml they don't have.

Solidity contracts now declare their publish version as a colon suffix on the existing package-name tag — the same convention as cdm i @org/name:1.2.1 (package names can never contain :):

/// @custom:cdm @org/mycontract:1.2.3
contract MyContract { ... }

The suffix is parsed where @custom:cdm is read (both /// line comments and /** */ blocks) and threaded through SolidityContractDefinition → build targets → ContractInfo.version. Semver validation stays centralized in resolveContractVersion — same rules as Rust (strict X.Y.Z, not 0.0.0, strictly greater than the registry's latest to publish) — but its error messages now give toolchain-appropriate advice: Cargo.toml [package].version for Rust, the :X.Y.Z tag suffix for Solidity.

EVM backend

Solidity contracts target pallet-revive's EVM backend, not resolc/PolkaVM:

• foundry builds run plain forge build (was forge build --resolc) — the upstream solc pipeline; artifact layout (out/<Source>.sol/<Contract>.json, bytecode.object) is identical in both modes, so the scanner is unchanged.
• the hardhat artifact scanner accepts upstream hh-sol-artifact-1 (what @parity/hardhat-polkadot emits in EVM mode) alongside hh-resolc-artifact-1; the hardhat template compiles EVM via polkadot: { target: "evm" }.
• pallet-revive distinguishes EVM initcode from PolkaVM blobs by magic bytes at upload, so the deploy path is shared. Cross-VM delegate_call (the PolkaVM per-name proxy delegating to an EVM implementation) is allowed by design — the interpreter is selected from the callee blob's BytecodeType with no cross-VM check, and polkadot-sdk's own test matrix covers resolc→solc delegatecall.

e2e coverage (new suite, live local PPN)

src/lib/contracts/tests/e2e/solidity.e2e.test.ts drives the real deployContracts pipeline on a copy of the foundry-counter template and proves against a live chain:

• both template contracts publish at the NatSpec-tagged version, dependency layer first, and the published registry key matches the tag exactly
• the built artifacts are EVM bytecode, not PolkaVM blobs
• a plain call through the PolkaVM per-name proxy executes the EVM implementation (cross-VM delegatecall)
• an EVM contract calls its dependency through the dependency's stable proxy address (baked in by the layered deploy's generated imports)
• an immediate redeploy skips everything as up-to-date (the NatSpec version gate)
• a tag bump republishes behind the same proxy over the same storage
• [MAGIC][key] versioned calls pin the previous EVM implementation over that shared storage

Full e2e run: 5 files, 54/54 tests green (bulletin, create3, proxy, registry, solidity). Unit suite, typecheck, and format all pass with the builder changes. CI's e2e job now installs foundry-polkadot (the suite needs forge; solc is auto-fetched). Hardhat is covered by unit tests plus a manual EVM-mode compile check (hh-sol-artifact-1, string bytecode) — no committed hardhat e2e, since it would hinge on a flaky npm install.

Closes #81