The permission boundary has no tests

[royalpinto007]

Why

Bridgekit's whole point is the permission boundary: an allowlisted table read, a
write tool that needs an explicit scope, and an audit row for every decision.
None of that has a test. The repo has six source files and zero test files, so
the invariants the README sells are currently held up by reading the code
carefully.

This is the kind of code where a refactor quietly inverts a boolean and nothing
tells you.

The invariants worth pinning

From src/connectors.ts and src/index.ts as they stand:

1. Table allowlist. dbRead accepts only posts, agents, tc_runs,
   tc_suites. Anything else throws table "x" is not readable. A test should
   assert the throw, not just that a good table works.
2. Write scope. index.ts:124 refuses a write: true tool when
   caller.config.allowWrite is false. Assert the refusal, and assert it happens
   before the connector is reached.
3. Denials are audited. The same branch writes an audit row with
   decision: "denied" and reason: "write scope required". A denial that is
   not recorded is the failure mode that matters here, so assert the audit call.
4. Tool visibility. tools/list at index.ts:91 hides write tools from a
   caller without the scope. Assert a scoped-down caller cannot even see them.
5. Per-client tool list. A tool absent from caller.config.tools is refused
   with tool "x" not allowed for this client, and audited.

Suggested shape

There is no test runner wired up yet, so step one is adding one. vitest fits a
Workers TypeScript project and needs no build step. The connectors take env as
a parameter, so they can be tested by passing a fake env with no credentials,
which is already the documented dry-run path.

Done when

• A test command exists in package.json and runs in CI
• Each of the five invariants above has a test that fails if the check is removed

Try deleting one guard and confirming a test goes red. A test that passes with
the guard deleted is not testing the guard.