feat(deploy): Slice A — hdb_deployment system table + audit record per deploy

[kriszyp]

Summary

Slice A of #641. Every deploy_component call now writes a row to a new system.hdb_deployment table capturing what was deployed, when, by whom, and whether it succeeded — plus the payload tarball itself as a Blob attribute. The deployment_id is returned in the deploy response and is the join key Studio/CLI will use to subscribe to live progress in Slice B.

This is the foundation layer for the broader deployment tracking, replicated payload delivery, and rollback design. Slices B and C will extend the same table with live ProgressEmitter integration (replacing #531), peer-side reads from the replicated blob (replacing #536/harper-pro#146), and rollback semantics.

Changes

• json/systemSchema.json: hdb_deployment table with deployment_id (UUID hash) plus the full lifecycle attributes
• utility/hdbTerms.ts: table-name constant and four new operation enums
• upgrade/directives/5-2-0.ts: provisions the table on existing installs (fresh installs get it via mount_hdb's systemSchema iteration)
• components/deploymentRecorder.ts: lifecycle wrapper used by deployComponent — creates the pending row, ingests payload into the Blob attribute with sha256 + size, commits the terminal status
• components/deploymentOperations.ts: list_deployments (filters: project, status, since, until, limit, offset) and get_deployment. Payload bytes are stripped from both — only payload_blob_present: boolean is exposed
• components/operations.js: deployComponent wraps prepareApplication in a try/catch driven by the recorder; payload is re-sourced from the persisted blob so extraction reads exactly what was recorded
• server/serverHelpers/serverUtilities.ts: registers the two new ops
• Brittle deepStrictEqual deploy-response assertions in 4 existing tests updated to allow the new deployment_id field

Scope deliberately deferred

• Streaming ingest: ingestPayload currently buffers the upload before persisting (race-free; multi-GB optimization comes in Slice B alongside the ProgressEmitter subscriber that also benefits from chunk-level progress events)
• Peer-side reads: Slice B reshapes peer execution to read the payload from the replicated hdb_deployment row's blob, replacing the staging temp file (feat(deploy): stage streamed payloads to a temp file for replication #536) and the direct-HTTPS relay (harper-pro#146)
• Rollback / reclamation: Slice C — deploy_component {rollback_from} arg + onStorageReclamation hook for per-node blob pruning

Test plan

• New integrationTests/deploy/deploy-tracking.test.ts — happy-path row write, list_deployments filtering, failure recording (4/4 pass locally)
• Existing deploy-multipart-stream.test.ts regression check (3/3 pass)
• Existing deploy-from-source.test.ts regression check (4/4 pass)
• npm run format:check clean on touched files
• oxlint clean on touched files
• CI green across the matrix

Refs #641

🤖 Generated with Claude Code

[claude]

2 blockers found (same pattern, operations.js deploy path).

1. Audit bypass via client-injected _deploymentId

File: components/operations.js:397
What: isReplicatedExecution is derived solely from typeof req._deploymentId === 'string'. A superuser can send {"operation":"deploy_component","_deploymentId":"x",...} and the recorder is never created — no row in system.hdb_deployment, no deployment_id in the response.
Why it matters: Breaks the PR's stated guarantee that every deploy_component call writes a row.
Suggested fix: Either strip _deploymentId from inbound bodies before the check, or have the replication layer mark the call out-of-band rather than relying on a user-controlled body field.

2. req.progress injection causes uncaught TypeError in deploy path

File: components/operations.js:398
What: emitter = req.progress ?? new ProgressEmitter() — if the client sends {"progress":{}}, emitter is {}. DeploymentRecorder.create({..., emitter: {}}) then calls {}.subscribe(...) → TypeError. This call is before the deploy try/catch, so the catch handler never runs and the deploy fails with a confusing 500.
Why it matters: Same pattern as the prior handleGetDeployment blocker (now correctly fixed at deploymentOperations.ts:89). The fix there — checking typeof x.emit === 'function' — needs to be mirrored here (or use instanceof ProgressEmitter since the import is available).
Suggested fix: const emitter = isReplicatedExecution ? null : (req.progress instanceof ProgressEmitter ? req.progress : new ProgressEmitter());

---

Prior blocker (finding #1 from last run — req.progress guard in handleGetDeployment) is resolved: deploymentOperations.ts:89 correctly gates on typeof (req.progress as any).emit === 'function', which JSON-parsed bodies can never satisfy.

[claude]

Audit bypass via client-injected _deploymentId.

Any superuser can skip audit-row creation by including "_deploymentId": "anything" in the request body. typeof req._deploymentId === 'string' is true, isReplicatedExecution is true, the recorder is never created, and the deploy proceeds with no row written to system.hdb_deployment. The response also omits deployment_id, so the client silently gets the pre-Slice-A shape.

The peer-replication use case needs a way to distinguish "this is a replicated call" from "a client happened to send this field." One approach: strip client-supplied _deploymentId early, before the recorder decision, and only trust it if it arrives via the replication-path context rather than the user-supplied body.

Suggested change

	const isReplicatedExecution = typeof req._deploymentId === 'string';
	const isReplicatedExecution = typeof req._deploymentId === 'string' && req._isReplicatedOperation === true;

…or, more robustly, have the replication layer mark the call out-of-band (e.g. on the request context) so _deploymentId in the body is no longer the sole signal.

[claude]

req.progress injection causes TypeError outside the deploy try/catch.

Same pattern as the prior blocker in handleGetDeployment (now fixed at deploymentOperations.ts:89), but here in the deploy path. A superuser sending {"operation": "deploy_component", "progress": {}} reaches this line with req.progress = {}, so emitter = {}. Then DeploymentRecorder.create({..., emitter: {}}) calls emitter.subscribe(...) → TypeError: emitter.subscribe is not a function. Because DeploymentRecorder.create is called before the try { … } catch block, the deploy's catch handler never runs — no recorder.finish('failed', err) and a confusing 500 to the client.

Suggested change

	// Slice B1 of #641: an SSE-bound caller already attached a ProgressEmitter (created in
	const emitter = isReplicatedExecution
	? null
	: req.progress instanceof ProgressEmitter
	? req.progress
	: new ProgressEmitter();
	if (!req.progress) req.progress = emitter;