[Feature] Add anchor-system semantic facade across SDK and Desktop

[ryan-wong-coder]

Problem

TrustDB currently models L5 integrations as narrow evidence sinks (Publish/Verify). This is sufficient for immutable STH anchoring, but upstream users cannot discover what kind of downstream system is configured or inspect provider-specific state such as nodes, blocks, transactions, accounts, or contracts.

Goal

Make TrustDB a semantic facade around downstream L5 anchor systems while preserving the existing immutable L5 evidence boundary. Expose a consistent model through HTTP, gRPC, the Go SDK, CLI/Admin surfaces, and Desktop.

Anchor system kinds

• timestamp_evidence: evidence-only/timestamp providers such as OpenTimestamps; publish, retrieve, and verify evidence.
• evidence_blockchain: blockchain without accounts/contracts; data synchronization, block production, and read-only node/block/transaction visibility.
• full_blockchain: complete blockchain capabilities including account and contract resources/operations.

Architecture requirements

• Keep immutable STHAnchorResult evidence separate from mutable system status and control-plane data.
• Identify configured provider instances by stable system_id; do not infer behavior from UI labels.
• Advertise versioned capabilities so SDK/Desktop can feature-detect.
• Support multiple provider instances in the long-term data model.
• Provide paginated, bounded resource inspection for nodes, blocks, transactions, accounts, and contracts.
• Extend the subprocess provider boundary without breaking existing Anchor Plugin v1 publish/verify implementations.
• Fail closed for provider/schema mismatches and never treat live status as L5 proof.
• Require explicit authorization, audit events, and disabled-by-default policy before exposing synchronization, block-production, signing, account, or contract mutations.

Delivery plan

Phase 1: semantic/read-only vertical slice

• Anchor system descriptor, kind, assurance properties, and capabilities.
• Status plus generic resource inspection model.
• HTTP and gRPC query APIs.
• Go SDK support.
• Desktop anchor-system overview/detail UI.
• Built-in descriptors for noop, file, and ots; optional explorer capability for external plugins.
• Design/specification and compatibility tests.

Phase 2: provider adapters and multi-system registry

• Production adapters for evidence blockchains and full blockchains.
• Multiple configured anchor-system instances and routing.
• Durable resource cursors/caching where provider APIs require it.

Phase 3: privileged operations

• Synchronization and block-production actions.
• Account transaction signing/submission and contract calls/deployment.
• RBAC, credential isolation, approval policy, rate limits, and immutable audit events.

Acceptance criteria

• Existing .sproof files and Anchor Plugin v1 implementations remain valid.
• Upstream clients can list anchor systems, retrieve status, and inspect declared resources through HTTP/gRPC/SDK/Desktop.
• Capability checks are enforced server-side.
• L5 verification continues to depend only on exact STH/binding verification.
• Privileged actions cannot be invoked unless the authorization and audit prerequisites are implemented and explicitly enabled.

[ryan-wong-coder]

Phase 1 implementation is available in #564. It delivers the semantic/read-only vertical slice across the provider protocol, HTTP/gRPC, Go SDK, and Desktop. Privileged synchronization/block-production/account/contract mutations remain tracked by this issue pending RBAC, credential isolation, and immutable audit prerequisites.