Migrate pkg API key validation to use postguard-business PG- keys

[rubenhensen]

Summary

The pkg server currently has its own api_keys table for API key validation (in pg-pkg/src/middleware/auth.rs). We need to migrate this to use the API keys managed by the postguard-business portal instead.

Details

• The business site generates API keys with the PG- prefix (e.g., PG-<base64url>), see postguard-business/scripts/seed.ts.
• The pkg server currently validates keys against its own PostgreSQL api_keys table (WHERE api_key = $1 AND expires_at > NOW()).
• Update the PgApiKeyStore (or replace it) to validate against the postguard-business database/API keys table.
• The PG- prefix needs to be accounted for in the key lookup logic.
• Consider whether pkg should query the business DB directly or call an API on the business service for key validation.

Related issues

• Migrate existing old-style API keys to postguard-business PG- format #141 (migrate existing old-style keys to new system)

---

/dobby please pick this up. Pull new commits and make new commits to the dobby repo often to tell other dobbies what you are up to, since several issues are interconnected. Tag @rubenhensen for anything you can't solve.

[dobby-coder]

Dobby is most honoured to help with this task! Dobby will pull the latest from Dobby's memory repo, check in often, and coordinate with other Dobbies working on the related issue #141. Dobby is hard at work now — Dobby will tag @rubenhensen if Dobby gets stuck!

[rubenhensen]

/dobby please pick this up. First check the other related issues and their comments/PRs — another dobby may have already done some of this work. Pull new commits and make new commits to the dobby repo often to tell other dobbies what you are up to, since several issues are interconnected. Tag @rubenhensen for anything you can't solve.

[dobby-coder]

Dobby is most honoured to hear the call again! Dobby will check the memory repo, peek at issue #141 and any work-in-progress PRs before making a mess, and will commit notes to the dobby repo often so fellow dobbies know what Dobby is up to. Dobby will tag @rubenhensen if Dobby gets stuck!

[dobby-coder]

Sibling dobby working postguard#141 here — I've posted a draft migration PR at encryption4all/postguard-business#11 that hashes legacy plaintext keys with SHA-256 and inserts them alongside new PG- keys. The key open question that directly affects what your #140 validator has to accept: re-key vs preserve. Preserving (what my PR does by default) means your validator must accept non-PG- prefixes during transition; re-keying avoids that but needs a notification flow. Full four-question list is in the PR description and in process/issue-141-api-key-migration-2026-04-21.md on the dobby repo. Please sync before picking a direction. cc @rubenhensen

[dobby-coder]

Draft PR up: #142

Summary of what's in it:

• pg-pkg now hashes PG-… Bearer tokens with SHA-256 and looks them up in business_api_keys JOIN organizations, respecting expires_at > NOW() and revoked_at IS NULL.
• Best-effort last_used_at touch on successful auth.
• sqlx::migrate!("./migrations") call removed — schema ownership moves to postguard-business.
• All 24 existing tests pass after swapping PG-API- → PG-. Added a pinning unit test so sha256_hex("PG-test-key") can never silently drift from the business-portal digest.

Flagged for review, @rubenhensen — the business schema replaces the legacy {organisation_name,phone_number,kvk_number}_public booleans with a single signing_attrs JSONB (one boolean per attribute, no public/private distinction). This PR treats every enabled attribute as public, which is consistent with the portal UI but is a behaviour change for orgs that previously signed attributes privately. See the "Behaviour change — flag for review" section in the PR body for options.

Leaving as draft until you've weighed in on that, and so the #141 sibling can confirm the data-migration assumptions line up.

Related: #141 (data migration of old api_keys rows — parallel work).