feat(cli): harper deploy setup=true — seal a durable deploy credential client-side

[dawsontoth]

Draft / prototype for #1778. Part of the create-harper deploy-by-reference effort.

harper deploy setup=true — a guided, client-side credential-provisioning flow (what harper login is for auth, but for deploy tokens):

1. get_secrets_public_key → the cluster's public key + fingerprint.
2. Source a token interactively — gh auth token, a pasted fine-grained PAT (Contents: Read-only), or npm token create for a private registry.
3. encryptEnvelope(...) → seal it locally into an enc:v1: envelope (pure client-side crypto; the plaintext never leaves the machine).
4. set_secret { envelope, grants:[component] } → store only ciphertext; the cluster decrypts it in-memory only at deploy/rollback time.
5. Print the credentials reference the deploy uses.

Because the token is durable (unlike a CI GITHUB_TOKEN, revoked at job end), a re-resolve rollback works for as long as it's valid. One flow unifies git-host ({host, …}) and npm-registry ({registry, …}) credentials.

Where: new bin/deploySetup.ts + a harper deploy setup=true intercept in bin/harper.ts. Builds on the credentials array (#1797), the git-host credential (#1799), and the hdb_secret client-side envelope (#1717); custody ships on by default (harper-pro#560). Parse + oxlint + prettier clean.

Refs #1778, #1797, #1799.

Related — deploy-by-reference effort

Prototype PRs: #1850 (deploy by_ref) · #1851 (deploy setup) · HarperFast/harper-pro#594 (add_ssh_key generate) · HarperFast/create-harper#118 (create-harper scaffold)

Tracking issues: #1777 · #1778 · HarperFast/harper-pro#570 · HarperFast/create-harper#117 · #641 (rollback)

[gemini-code-assist]

Code Review

This pull request introduces an interactive client-side setup flow (deploySetup) to securely provision and seal credentials for private GitHub repositories or npm registries using the cluster's public key. It also updates the main CLI entry point to intercept and route the setup command. The review feedback highlights several critical issues: a mismatch in the secret naming convention for git hosts compared to the server-side implementation, a missing argument in the secret name derivation call, a lack of validation for unsupported providers, a potential runtime TypeError if the token is not a string, and the need for a more robust truthiness check on the setup flag to handle stringified booleans like 'false' or '0'.

[gemini-code-assist]

When CLI arguments are parsed, boolean-like flags can sometimes be represented as strings (e.g., "false" or "0"). Relying on a simple truthiness check on cliApiOp.setup can cause the setup flow to run even when the user explicitly passes setup=false. We should use a more robust check to ensure setup is not a falsy string.

Suggested change

	if (cliApiOp.operation === 'deploy_component' && cliApiOp.setup) {
	const { deploySetup } = require('./deploySetup');
	await deploySetup(cliApiOp);
	return;
	}
	if (cliApiOp.operation === 'deploy_component' && cliApiOp.setup && cliApiOp.setup !== 'false' && cliApiOp.setup !== '0') {
	const { deploySetup } = require('./deploySetup');
	await deploySetup(cliApiOp);
	return;
	}

References

1. When evaluating boolean-like environment variables in JavaScript or TypeScript, avoid relying on simple truthiness checks because environment variables are always strings, meaning values like 'false' or '0' are truthy. Instead, use explicit checks to treat '0' and 'false' as falsy.

[dawsontoth]

Leaving this as-is: buildRequest JSON-parses each key=value arg, so setup=false becomes boolean false and setup=0 becomes 0 (both falsy) before this check runs — the stringy 'false'/'0' case can't reach here. The truthiness check is already correct.

🤖 Addressed by Claude Code

[claude]

Reviewed; no blockers found. The prior blocker (deriveSecretName mismatched the server's git-host secret naming) and both non-blocking suggestions (non-string token= guard, provider validation) are all fixed in 7e18907 — verified deriveSecretName now matches deriveGitSecretName/deriveRegistrySecretName/normalizeGitHost in components/secretOperations.ts / components/gitCredentialServer.ts exactly.