Add black-box system E2E and multisig qualification

[zeljkoX]

Summary

Add automated end-to-end qualification for the assembled Guardian system: the release-style Docker image, Postgres, base clients, operator client, and both multisig SDKs.

Existing CI covers server modules, in-process E2E, Postgres implementations, and individual packages, but it does not prove that these components work together through real HTTP and gRPC boundaries. This is an umbrella issue; each phase may be delivered as a subissue.

Phase 1: deterministic system E2E

Create a locally runnable harness and GitHub Actions workflow that:

• Builds the server-runner image with the postgres feature and current Git SHA.
• Starts Guardian and Postgres in isolated containers and waits for readiness with a bounded timeout.
• Verifies /status, including version, Git commit, and environment.
• Runs fixture account/proposal flows through:
  • @openzeppelin/guardian-client over HTTP.
  • guardian-client over gRPC.
• Verifies at least one structured API error.
• Restarts only Guardian and confirms account, state, and proposal data remain accessible.
• Captures test output, Guardian logs, and container state on failure.
• Always removes test containers and volumes.

Run this workflow on relevant pull requests, pushes to main, and workflow_dispatch.

Phase 2: operator API E2E

Exercise @openzeppelin/guardian-operator-client against the real Postgres-backed server:

• Authenticate with a deterministic Falcon operator key.
• Establish and inspect a session.
• List accounts and fetch account details.
• Verify denial for an operator lacking the required permission.
• Verify allowlist hot reload without restarting Guardian.
• Log out and confirm session invalidation.
• Verify relevant audit events persist in Postgres.

Phase 3: Miden multisig canaries

Run complete user-facing flows against the configured Miden test environment for both miden-multisig-client and @openzeppelin/miden-multisig-client:

• Create and register a multisig account.
• Create a proposal, collect threshold signatures, and execute it.
• Synchronize and verify state commitment and Guardian convergence.
• Cover Falcon and ECDSA signers.
• Cover online execution and offline export/sign/import.
• Cover SwitchGuardian.
• Verify Rust and TypeScript behavioral parity.

Because these tests depend on an external Miden environment, run them nightly and through workflow_dispatch, not as required pull-request checks. Expensive variants may rotate across runs, but disabled flows must be reported as skipped rather than passed.

Acceptance criteria

• One command runs the deterministic system test locally.
• CI tests the real Docker image through public HTTP and gRPC ports.
• Both base clients complete their fixture flows.
• Postgres data survives a Guardian restart.
• Operator authentication, authorization, hot reload, logout, and audit persistence are automated.
• Nightly Rust and TypeScript multisig lifecycle coverage exists.
• Falcon, ECDSA, online, offline, and SwitchGuardian paths are covered.
• Readiness checks use timeouts rather than arbitrary sleeps.
• Failures preserve bounded diagnostics without exposing secrets or signed payloads.
• Third-party actions are pinned and workflow permissions are minimal.
• Local and CI execution is documented.

Out of scope

• Automated Anvil/EVM proposal coverage.
• Package tarball/downstream-consumer qualification.
• Redesigning releases to gate publication on an exact qualified SHA.
• Load or production testing.