feat(observability): add structured logging foundation

[ryan-wong-coder]

Linked Issue

Fixes #5

Summary

• add a reusable zerolog 1.35.1 structured logging foundation aligned with TrustDB's explicit injection model
• fail closed on invalid level, format, nil writer, and uninitialized logger use
• emit synchronous JSON or no-color console logs with stable event/component metadata, timestamps, and one shared monotonic sequence
• document the implemented logging boundary without claiming a node runtime, API, persistence, or production readiness

Required Format

• Branch name: feat/structured-logging-foundation
• PR title and commit use Conventional Commits.

Scope And Project Status

• This PR solves one issue or one clearly scoped maintenance task.
• This PR excludes unrelated formatting, experiments, generated files, local data, credentials, logs, captures, and build artifacts.
• User-facing material distinguishes implemented behavior, target design, and roadmap work.
• Any performance claim identifies its source, hardware, configuration, measurement method, and whether it is a FinalWeave result.

No performance claim is introduced.

Protocol, Safety, And Compatibility

• This PR does not change quorum, Byzantine fault, proposer-slot, stable-prefix, or epoch-transition rules.
• BatchAC still proves recoverable data availability only; it is not treated as transaction validity, ordering, or execution finality.
• Canonical ordering and speculative parallel execution remain deterministic and equivalent to canonical serial Apply.
• External finality remains bound to an authenticated Header, exact FinalityCertificate, locally trusted validator/config chain, and query-specific proofs.
• This PR does not change canonical encoding, domain separation, signatures, IDs, state commitments, or wire schemas.
• WAL, atomic publication, snapshots, pruning, synchronization, replay, and recovery preserve their durable safety boundaries.
• This PR does not change networking, admission, cross-ledger proof validation, or resource-accounting boundaries.
• No production path introduces unbounded scan, sort, load, verification, retry, amplification, or recomputation behavior.

The new package is an operational adapter only. It starts no goroutine, listener, queue, retry loop, storage, or protocol path. Log calls synchronously write bounded caller-supplied events and may apply writer backpressure. Callers remain responsible for attaching only bounded, allowlisted metadata; payloads, secrets, raw transactions, and provider error details are explicitly prohibited.

Validation

• git diff --check
• python3 scripts/check_docs.py
• go mod verify and a clean go mod tidy diff
• go vet ./...
• go test -count=1 -mod=readonly ./...
• go test -race -count=1 -mod=readonly ./...
• python3 scripts/check_go_architecture.py
• Relevant unit, race, property, fuzz, vector, model, Byzantine, partition, crash-recovery, snapshot, chaos, and performance checks
• Negative tests cover malformed, conflicting, stale, replayed, oversized, and partially durable inputs where applicable

Focused tests cover JSON fields, timestamp format, component derivation, concurrent monotonic sequences, level filtering, console output, disabled logging, invalid enums, nil and typed-nil writers, uninitialized use, and zerolog global-state isolation. Protocol vectors, model, Byzantine, partition, recovery, snapshot, chaos, and performance tests are not applicable because this PR changes no protocol, network, storage, lifecycle, or asynchronous path.

Risk And Rollback

The main operational tradeoff is synchronous writer backpressure; this is intentional so the first safety-oriented foundation cannot silently drop events. Console formatting adds zerolog's terminal-formatting transitive dependencies. Roll back by reverting this PR; no schema, wire format, persisted state, migration, or compatibility transition is involved.