[alexhraber]

Summary

Prepare #93 up to the point of running a compatible service, without requiring a hosted instance.

• Add opt-in local PostgreSQL service and protected hosted profiles through Dactyl's public Connection API.
• Exercise typed scalar/null/blob bindings, exact rows, generated-key responses, affected counts, stale CAS, ordered atomic batches, rollback, opaque contexts, authentication/authorization denials, read-only enforcement, unsupported capabilities, and no fallback.
• Supply a small disposable SQL fixture and safe operator instructions. The external service owner supplies the authenticated /query and /batch implementation and independent PostgreSQL observer.
• Keep fixture credentials out of receipts, reserve new private receipt files without overwriting, and leave backend/identity/cleanup/pooler evidence explicitly pending.
• Add nine network-free readiness checks and a CI guard that requires an explicitly requested profile with no fixture to fail.

Verification

• cargo test --locked --all-features: 76 passed, 0 failed, 2 real-service profiles ignored
• cargo test --locked --no-default-features: passed
• Supabase-only profile readiness tests: 9 passed
• cargo clippy --locked --all-targets --all-features -- -D warnings: passed
• cargo fmt --all -- --check and git diff --check: passed
• Explicit local profile without its fixture: failed as required with unavailable is not a pass
• Repository-pinned Decapod 0.105.0 validation: passed

Automatic GitHub Actions

Exact head e2ffc018cb00bb490b6968e653ec59d4b95b5be7 passed:

• Rust Contract: contract tests, missing-fixture failure guard, optional feature combinations, formatting and clippy
• Decapod Validate: governance validation and no generated-spec/entrypoint drift

These jobs did not run either real-service profile.

Still required before backend acceptance

No compatible authenticated PostgreSQL service fixture or hosted Supabase instance was available, so neither real-service profile has run. The offline results establish harness readiness only.

An operator must provide a fresh disposable database and compatible service, provision the allowed and denied principal/context fixtures, execute the profile, independently verify persisted state and unchanged schema, inspect transaction/authorization enforcement, and verify cleanup. Hosted acceptance and each connection/pooler mode require their own protected runs. A client receipt alone does not establish these results.

This PR does not close #93. See the run instructions.