feat(contracts): cover the three Platform Verifiers

[xgreenx]

The three Platform Verifiers have their sources here but the crate did not carry them, so a deployer (chain-configurations #8) reimplemented Artifacts and the sol! interfaces to deploy one.

Changes

• Vendor XPlatformVerifier, GitHubPlatformVerifier, GooglePlatformVerifier (COVERED + vendor-artifacts.sh, in sync).
• bindings::ceremony: TlsNotaryPlatformVerifier (exported as XPlatformVerifier and GitHubPlatformVerifier; one shared surface) and GooglePlatformVerifier, with initialize, views, setters, ceilings, events, initializer errors.
• platform_verifier: Initializer::{X,GitHub,Google} checks what __PlatformVerifierBase_init refuses (notary per profile, zero addresses, ceilings), reads the Honk verifier's code hash off chain (codehash_at) and builds the typed initialize call; deploy_platform_verifier puts the implementation behind an ERC1967 proxy with it.
• Error::Initializer for refusals caught before any transaction.
• Unit tests pin bound selectors to the vendored methodIdentifiers and notarizes() to the libid-profiles table (path-only dev-dependency, stripped at publish).
• Anvil test deploys all three through the wrapper, checks every view, registers each with the Proof Verifier, and shows the wrapper's refusals are the contract's reverts.
• Crate README: Platform Verifier example.

Verified

• forge test: 479 passed.
• cargo +nightly fmt --check, clippy --all-targets --all-features -D warnings, cargo test --all under RUSTFLAGS=-D warnings: 9 unit + 5 anvil tests pass (new anvil test 0.5 s); cargo doc -D warnings clean.

Not verified / known issues

• The bb-generated UltraHonk verifiers are not shipped; judgment in the first comment.
• @libid/contracts (TS) lists no Platform Verifier ABI; out of scope.
• The anvil test stands in a plain contract for the Honk verifier: initialize pins a code hash and never calls verify.

[xgreenx]

Should this crate also ship the two bb-generated UltraHonk verifiers? No.

Facts:

• libid-circuits v0.3.0 releases manifest.json (version, bb version, sha256 per file) and two tarballs (bearer-link, oidc-google) carrying the verification keys. No Solidity: the verifier is bb write_solidity_verifier -k vk at the manifest's bb version, then two canonical renames, then forge build. It links ZKTranscriptLib and RelationsLib.
• This crate's charter is "kept in lockstep with the Solidity sources in solidity/contracts". A Honk verifier has no source here; its input is another repo's release asset.

Cost of doing it here: a committed circuits pin, bb at the pinned version installed in the four CI jobs that vendor (solidity, rust, publish-check, publish-crates), a network fetch and sha256 check inside vendor-artifacts.sh, and a coupled release cadence — every circuits release would force a contracts release, and every contracts release would re-ship the same verifier bytecode. PlatformVerifierBase pins the artifact by code hash exactly so the two can move independently through setTrustRoots.

Recommendation: keep them out. The linking path (Artifacts::linked_bytecode, Artifacts::from_dir) already deploys such an artifact from a directory. The cleaner move is for libid-circuits' release workflow to publish the compiled verifier artifacts (creation code + linkReferences, as forge emits them) alongside the vk, so a deployer downloads and links rather than runs bb — that removes bb from chain-configurations as well.