Make Communities.kfOrgId nullable and rename it kfAccountId - #3689

Ahead of the kf-console cutover (kf-console replaces kf-auth as PubPub's OIDC provider). The console creates no personal org at sign-up, so someone who signs up after cutover has no orgs, and if 2026_06_15_makeKfOrgIdNotNull has been run, their community insert fails. The model, the API schema, the server insert and the create form already treat kfOrgId as optional; only that constraint blocks them.

• New tools/migrations/2026_10_05_makeKfOrgIdNullable.js: up drops NOT NULL (safe whether or not the old migration ran, idempotent); down restores it, refusing while NULLs exist.
• 2026_06_15_makeKfOrgIdNotNull up now throws "superseded" so it isn't run by mistake.
• Community create: a picked kfOrgId is kept only if the user belongs to that org (per fetchUserOrgs); otherwise, or if the lookup fails, the community is created with NULL. Users with no orgs never trigger the lookup.
• Model comment: kfOrgId is the account a community is billed to, staff-set, NULL until assigned.
• Tests: create with no orgs → NULL; picked org kept when a member, dropped when not.
• Rename kfOrgId → kfAccountId (old terminology; in the console these are accounts). New migration 2026_10_05_renameKfOrgIdToKfAccountId.js renames the column and both indexes (communities_kf_org_id_idx and the sync-made communities_kf_org_id), reversible. Model, schemas, create/transfer paths, client and copy ("KF Account") follow. The model no longer declares @Index: sequelize.sync() runs before migrations and would try to index a column that doesn't exist yet; the migrations own the index.
• Wire compatibility: /api/kf/summary and /api/kf/billing/usage accept kf_account_id and still kf_org_id (kf-console and Hubs call ?kf_org_id=); transfer accepts kfAccountId and still kfOrgId. The IdP's orgs claim, /api/internal/users/:id/orgs and /api/kf/my-orgs are the console's contract and keep their names.

Run order: pnpm tools migrate --name 2026_10_05_makeKfOrgIdNullable, then --name 2026_10_05_renameKfOrgIdToKfAccountId, at deploy (the new code selects kfAccountId). Roll back in reverse with --down.

Checked: pnpm run check, biome on touched files, server/community/__tests__/api.test.ts (10/10), the new server/kf/__tests__/api.test.ts (14/14 together), and both new migrations up and down against a local test database (from a NOT NULL, double-indexed starting state, data kept).

Needs, before the cutover:

• Has makeKfOrgIdNotNull been run on prod (and duqduq)? Either way makeKfOrgIdNullable should run before cutover.
• Where do staff set kfOrgId? Today nothing lets them (transfer requires membership in the target org). One option: add it to the superadmin-only update fields in server/community/permissions.ts.
• Communities with NULL kfOrgId are invisible to /api/kf/summary and billing usage — who sees the unassigned list?
• Since new users won't have personal orgs, should the create picker and user-driven transfer go away entirely?
• fetchUserOrgs has no timeout (unlike the other auth-server calls); worth fetchWithTimeout.