Plan CI jobs for live-database and Docker-backed tests

Summary

Create a sysadmin-reviewed plan for expanding Apiary CI beyond the hermetic root-package checks introduced in #103.

This follow-up is extracted from #100 so infrastructure and credential decisions can be discussed separately from application test improvements.

Current state

• .github/workflows/test.yml builds and vets all packages.
• Root-package tests run with the race detector.
• The Gnomock-based db package test is compiled but not executed because it requires a Docker daemon.
• The cmd/apiary integration suite is run locally against a configured PostgreSQL database and currently depends on the live Apiary schema and data.

Decisions requiring sysadmin input

• Decide whether live-database tests should use an isolated CI database, sanitized fixture database, or another environment.
• Define how database credentials and network access should be provided without exposing or mutating production data.
• Confirm whether the Gnomock test can safely run against the available GitHub Actions Docker daemon or should use a dedicated runner.
• Decide which suites should gate pull requests and which should run on a schedule or by manual dispatch.
• Define timeouts, concurrency, and failure/notification expectations.
• Document the agreed operational model before enabling the new jobs.

Related work

• #103 established the current hermetic CI baseline.
• #100 continues to track deterministic live-database tests and root-package unit coverage. Those application-level improvements can proceed without waiting for this infrastructure decision.

This issue is intentionally deferred for discussion with the sysadmin and does not block or alter the audit work already merged.

Start with .github/workflows/test.yml and the current hermetic baseline from #103, then review the live-database and root-package testing context in #100. Consult the sysadmin on database isolation, credentials, Docker availability, gating, scheduling, and notifications. Done means the operational model is agreed and documented before new CI jobs are enabled.