feat(artifacts): prefer server-assembled bundle delivery for downloads

[riglar]

What

Artifact and HTML-report downloads now try a bundle-delivery path before the inline download:

1. The CLI calls a manifest endpoint (GET /results/{uploadId}/artifacts-bundle?results=… or …/report-bundle).
2. The API returns a signed manifest plus a URL to a delivery service that streams the ZIP straight from storage.
3. The CLI relays the signed { manifest, sig } to that URL — no auth header, since the manifest is itself the signed access token — and streams the ZIP to disk.

Large downloads stream directly from storage instead of flowing through the API.

Compatibility

Fully backwards-compatible, no version negotiation:

• Delivery not offered (older deployment / not configured) → manifest endpoint returns 501 → the CLI falls back to the existing inline download.
• Anything else about the bundle path doesn't pan out (non-OK manifest, unexpected body, delivery-service error) → same graceful fallback. Definitive errors (e.g. not found) still surface through the inline path.
• Only artifacts and the HTML report use bundle delivery; junit (a single small file) and allure (separate endpoint) keep their existing paths.

How

• New shared tryBundleDownload helper in the API gateway; downloadArtifactsZip and the HTML branch of downloadReportGeneric call it first and fall back on false.
• The inline download code paths are unchanged.

Testing

• pnpm typecheck + pnpm lint clean.
• pnpm test — 171 passing, including new coverage: streams from the bundle URL and skips the inline endpoint, sends no auth header to the (pre-signed) bundle URL, falls back to inline on 501, and uses bundle delivery for the HTML report. Existing inline-download tests unchanged.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[claude]

This final streamResponseToFile call is the one failure mode in tryBundleDownload that isn't converted to return false. Every other step (fetch manifest, json(), missing fields, bundle POST, !zipRes.ok) is guarded and falls back to inline. But streamResponseToFile throws on a mid-stream failure — a dropped/truncated connection during the ZIP download, or a null body on an otherwise-OK response (it explicitly throws when res.body === null, and pipeline propagates source-stream errors):

dcd-cli/src/gateways/api-gateway.ts

Lines 246 to 250 in 8e6e796

	}
	await this.streamResponseToFile(zipRes, destinationPath, operation);
	return true;
	},

Because both call sites invoke this as an if (await this.tryBundleDownload(...)) return; condition that sits before the inline try block, a throw here escapes past the inline /download fallback entirely — contradicting the PR's stated intent ("falls back silently to inline /download on 501 or any bundle-path failure") and leaving a partial file on disk. Wrapping the stream so it returns false restores the fallback (the inline path re-opens the destination with flags: 'w', so the partial file is truncated on retry):

Suggested change

	await this.streamResponseToFile(zipRes, destinationPath, operation);
	return true;
	try {
	await this.streamResponseToFile(zipRes, destinationPath, operation);
	} catch {
	return false;
	}
	return true;