Implement trusted setup ceremony infrastructure for Groth16 circuits

[Copilot]

Implements multi-party computation ceremony infrastructure for generating production Groth16 proving/verification keys. Currently, circuits use setup() which generates insecure test keys. Production requires ceremony-generated keys with proper toxic waste destruction.

Core Infrastructure

• key_management.rs: Key serialization/deserialization with SHA-256 hashing for verification
• Circuit key loading: load_proving_key(), load_verification_key(), load_ceremony_keys() on BattleCircuit and StateCircuit
• Directory structure: keys/{battle,state}/ for keys, ceremony/{tools,attestations,transcripts}/ for ceremony artifacts

// Before (insecure for production)
let (pk, vk) = BattleCircuit::setup()?;

// After (loads ceremony keys)
let (pk, vk) = BattleCircuit::load_ceremony_keys()?;

Ceremony Documentation (2,600+ lines)

• docs/CEREMONY.md: Security model, timeline, verification procedures
• ceremony/participant_instructions.md: Entropy generation, contribution workflow, toxic waste destruction
• ceremony/coordinator_checklist.md: Infrastructure setup, participant sequencing, publication workflow
• keys/README.md: Verification procedures, distribution channels (GitHub/IPFS/BitTorrent)
• Supporting READMEs for tools, attestations, transcripts, and circuit-specific keys

Security Model

• Random beacon: Bitcoin block hash initialization
• Contribution proofs: Each participant's randomness cryptographically verified
• Audit trail: Public transcript with all contributions, hashes, attestations
• 1-of-N trust: Keys secure if ≥1 participant destroys toxic waste

Tool Specifications

Defined architecture for:

• ceremony-contribute: Entropy collection, parameter mixing, proof generation
• ceremony-coordinator: Participant sequencing, contribution verification, key finalization
• ceremony-verify: Contribution validation, transcript verification
• ceremony-audit: Statistical reports, independence verification

Tool implementation scheduled for pre-ceremony (Q1 2026).

Path Handling

Key loading uses proper error handling instead of .unwrap() chains:

let manifest_dir = std::path::Path::new(env!("CARGO_MANIFEST_DIR"));
let repo_root = manifest_dir
    .parent()
    .and_then(|p| p.parent())
    .ok_or_else(|| crate::Error::KeyManagement(
        "Failed to resolve repository root from crates/bitcell-zkp".to_string()
    ))?;

Expected structure documented in method docstrings.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Conduct Trusted Setup Ceremony and Verification Key Management</issue_title>
<issue_description>Part of Epic: #72 - RC2: Zero-Knowledge Proof Production

---

Goal: Set up production ready Groth16 proving and verification keys using multi-party computation ceremony.

Requirements:

• Conduct multi-party trusted setup for circuits
• Ensure destruction of toxic waste
• Publish keys, document ceremony and invite contributors

Acceptance Criteria:

• Setup completed with audit trail
• Keys published and verifiable by third-party

See RELEASE_REQUIREMENTS.md</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Conduct Trusted Setup Ceremony and Verification Key Management #48

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR implements a comprehensive trusted setup ceremony infrastructure for generating production-grade Groth16 proving and verification keys. The implementation replaces the insecure setup() method (which uses test randomness) with a multi-party computation (MPC) ceremony framework that ensures cryptographic security through the "1-of-N" trust model - keys remain secure as long as at least one ceremony participant properly destroys their toxic waste.

Key changes:

• Added key_management.rs module with serialization, deserialization, and SHA-256 hashing for proving/verification keys
• Extended BattleCircuit and StateCircuit with load_proving_key(), load_verification_key(), and load_ceremony_keys() methods
• Created 2,600+ lines of comprehensive documentation covering security model, participant instructions, coordinator checklists, and verification procedures
• Established directory structure: keys/{battle,state}/ for keys, ceremony/{tools,attestations,transcripts}/ for ceremony artifacts

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/bitcell-zkp/src/key_management.rs	Core key serialization/deserialization module with SHA-256 hashing and comprehensive test coverage
crates/bitcell-zkp/src/battle_circuit.rs	Added ceremony key loading methods with proper path resolution and error handling
crates/bitcell-zkp/src/state_circuit.rs	Added ceremony key loading methods mirroring BattleCircuit implementation
crates/bitcell-zkp/src/lib.rs	Exported key_management module and added KeyManagement error variant
docs/CEREMONY.md	510-line comprehensive guide covering security model, timeline, and verification procedures
ceremony/participant_instructions.md	606-line detailed participant guide with entropy generation, contribution workflow, and toxic waste destruction instructions
ceremony/coordinator_checklist.md	391-line coordinator guide with pre-ceremony, ceremony, and post-ceremony checklists
keys/README.md	365-line key verification and usage guide with distribution channels and security notes
keys/battle/README.md	BattleCircuit-specific key documentation with circuit details and verification instructions
keys/state/README.md	StateCircuit-specific key documentation with circuit details and verification instructions
ceremony/tools/README.md	307-line tool architecture documentation for ceremony-contribute, ceremony-verify, ceremony-coordinator, and ceremony-audit
ceremony/transcripts/README.md	178-line transcript format specification and verification checklist
ceremony/attestations/README.md	83-line attestation format and verification guide
keys/.gitignore	Configures git to ignore large binary key files while preserving documentation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Inconsistent tool name: this uses ceremony-verify-full but the ceremony tools documentation (ceremony/tools/README.md lines 116-118) shows the tool is simply ceremony-verify with --transcript and --keys arguments. The binary name should be consistent across all documentation.

Suggested fix:

cargo run --release --bin ceremony-verify \
  --transcript ../transcripts/battle_transcript.json \
  --keys ../../keys/battle/

Suggested change

	cargo run --release --bin ceremony-verify-full \
	cargo run --release --bin ceremony-verify \