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.

tests/authz.test.ts

@@ -3,6 +3,10 @@ import { Elysia } from "elysia";
 import { toErrorResponse } from "@continuum/ts-core";
 import { roleSatisfies, ORG_ROLES } from "../src/auth/roles";
 import { startDevAuthIssuer } from "../scripts/dev-auth";
+import { Value } from "@sinclair/typebox/value";
+import { printers } from "../src/db/schema";
+import { farmProjection, printerProjection } from "../src/db/projections";
+import { PrinterCreateSchema } from "../src/db/validators";
 
 const USER = "11111111-1111-1111-1111-111111111111";
 
@@ -249,3 +253,58 @@ describe("object storage configuration", () => {
     }
   });
 });
+
+/**
+ * The credentials this backend is not allowed to hold or hand out.
+ *
+ * `printers.accessCode` used to exist: writable through `POST /printers`,
+ * excluded from the projection, and never read by any backend code path - a
+ * printer's LAN password at rest in the cloud for no purpose. It was removed
+ * (2026-10-19) because the credential belongs on the proxy, the only thing
+ * that uses it, and the alternative of surfacing it in the UI was considered
+ * and rejected: useful, but not worth the risk.
+ *
+ * These tests exist so that decision is enforced rather than remembered. A
+ * column is easy to re-add, and the symptom would be silent.
+ */
+describe("credentials the backend must not hold", () => {
+  test("a printer has no access-code column to store one in", () => {
+    // Against the Drizzle table rather than live SQL, so it fails in CI with
+    // no database - the point is the declaration, not this machine's schema.
+    expect(Object.keys(printers)).not.toContain("accessCode");
+  });
+
+  test("a client that sends one anyway has it dropped, not stored", () => {
+    // The create schema is open, so a stray field validates. Elysia cleans
+    // the body against the schema, which is what actually discards it - so
+    // the honest description is "ignored", not "rejected". Worth pinning:
+    // if the field ever became retained, nothing else here would notice.
+    const body = {
+      farmId: "3f2b1c5e-0000-4000-8000-000000000000",
+      name: "P1P",
+      vendor: "bambu" as const,
+      accessCode: "SECRET123",
+    };
+    const cleaned = Value.Clean(PrinterCreateSchema, structuredClone(body)) as Record<string, unknown>;
+    expect(cleaned).not.toHaveProperty("accessCode");
+    expect(cleaned.name).toBe("P1P");
+  });
+
+  test("the farm's edge proxy token is still kept out of responses", () => {
+    // The credential that does remain. `POST /auth/edge-token` trades it for
+    // an edge JWT, so with it and a farm id anyone can connect as that
+    // farm's gateway and drive its printers.
+    expect(Object.keys(farmProjection.columns)).not.toContain("edgeProxyToken");
+  });
+
+  test("metadata is the remaining way a secret could reach the cloud", () => {
+    // Not a bug to fix here, but a hole to know about: `metadata` is a
+    // free-form jsonb column that is both writable and in the public
+    // projection, so a well-meaning client could stash an access code in it
+    // and the API would store it and serve it back. Removing the dedicated
+    // column narrowed the door; it did not close it. If this assertion ever
+    // fails because `metadata` left the projection, that is an improvement -
+    // delete the test.
+    expect(Object.keys(printerProjection.columns)).toContain("metadata");
+  });
+});