Stop storing printers' access codes

`printers.access_code` held a printer's LAN password - the same value Bambu
uses for MQTT and as the FTPS password. It was writable through
`POST /printers`, excluded from `printerProjection` so it could not leave the
server, and **never read by any backend code path**. A secret at rest in the
cloud, serving no purpose.

The credential belongs on the proxy, which is the only thing that uses it.
Under the three-tier architecture it goes FE -> API -> proxy, with the API
relaying it rather than persisting it.

Considered and rejected, deliberately: keeping the column so the console
could show an operator their printer's access code. Useful, but not worth the
risk. Removing the column is what makes that rejection real - a stored secret
is one a future route can leak, and the projection was the only thing
standing between this column and a response.

`PRINTER_WRITABLE` and the two schemas derived from it move to
`db/validators.ts`, which already declares itself the single place these
shapes are defined. The reason is testability: a route imports `db/index.ts`
and so needs a live `DATABASE_URL`, and "what may a client set" is exactly
the kind of thing worth asserting with no database in sight.

Four tests pin the decision so it is enforced rather than remembered, because
a column is easy to re-add and the symptom would be silent. One of them
records a hole rather than a fix: `metadata` is a free-form jsonb column that
is both writable and in the public projection, so a well-meaning client can
still stash a credential there and have it stored and served back. Removing
the dedicated column narrowed the door; it did not close it.

The e2e script still submits `accessCode: "SECRET123"` on purpose. The field
is now unknown to the create schema, the schema is open, and Elysia cleans it
away rather than rejecting the request - so the canary proves against a real
server that a client which tries to hand the cloud a credential has it
dropped and never echoed. That is runtime behaviour the unit test can only
establish at the schema level.

Migration 0003 is a single `DROP COLUMN IF EXISTS`, applied locally. There is
no production, staging or dev environment and nothing was writing the column,
so there is no data to preserve and no consumer to break.

scripts/e2e-authz.sh

@@ -186,12 +186,19 @@ FARM_A="$(json 'd["id"]')"
 body_lacks edgeProxyToken
 ok "farm A = $FARM_A, and the create response carries no proxy token"
 
+# `accessCode` is deliberately still sent, even though the column was removed
+# (2026-10-19) and the field is now unknown to the create schema. That is the
+# point: a client that believes it can hand the cloud a printer's LAN password
+# must have it dropped and never see it again. The schema is open, so the
+# field validates and Elysia cleans it away rather than rejecting the request
+# - which is behaviour worth proving against a real server, not just against
+# the schema (see the credentials block in tests/authz.test.ts).
 expect 201 POST /printers "$OWNER_A" \
   "{\"farmId\":\"$FARM_A\",\"name\":\"e2e printer A\",\"vendor\":\"bambu\",\"accessCode\":\"SECRET123\",\"serialNumber\":\"SN-SECRET\"}" \
-  -- "owner_a adds printer A with an access code"
+  -- "owner_a adds printer A, trying to set an access code"
 PRINTER_A="$(json 'd["id"]')"
 body_lacks SECRET123
-ok "printer A = $PRINTER_A, and the create response carries no access code"
+ok "printer A = $PRINTER_A, and the submitted access code was dropped, not echoed"
 
 echo "==> building org B (via the API, as the outsider)"
 expect 201 POST /orgs "$OUTSIDER" '{"name":"e2e org B"}' -- "outsider creates their own org B"