Verify Neo4j's Access-gated remote entry (neo4j.omnibioai.org / Cloudflare Access) is actually configured

[man4ish]

Context

v0.7.1's changelog claimed Neo4j hardening included "Access-gated remote entry." A post-release audit (2026-09-14) verified the other two parts of that claim against real evidence:

• Network restriction: confirmed real. docker-compose.yml's neo4j service binds Browser/Bolt to 127.0.0.1 only (commit 6324e801), confirmed live via docker ps.
• Credential rotation: was false, now genuinely fixed. See the v0.7.1 erratum in docs/CHANGELOG.md (2026-09-14) and this commit's own history — the stale credential was reset for real tonight, verified with before/after cypher-shell checks.

This issue is the one part that could not be verified either way, because it's infra-level (Cloudflare dashboard / cloudflared tunnel config), not something visible from any repo checked in this audit.

What needs to happen

Someone with Cloudflare dashboard/account access needs to confirm:

1. neo4j.omnibioai.org actually has a Cloudflare Access policy attached (not just a plain tunnel to localhost:7474).
2. The policy is scoped appropriately (who's allowed through) — not left in a default-allow or misconfigured state.
3. Bolt (7687) isn't separately exposed through the same or a different tunnel without equivalent gating (the loopback-only bind in docker-compose protects the LAN path; it says nothing about what the cloudflared tunnel itself exposes).

Why this matters

Neo4j now has a real password again as of tonight, but if the claimed Access-gating on the remote entry point turns out to be missing or misconfigured, that's a second path to the same knowledge-graph data that the docker-compose network restriction doesn't cover at all.