ci: remove the preview-deploy workflows and the credential they carry

[sh4mbhavi]

Summary

Deletes .github/workflows/pr.preview-deploy.yml, pr.preview-teardown.yml and
pr.preview-instructions.yml, and corrects the three README paragraphs that described them.

Type of Change

• Security - [x] CI/CD / infrastructure - [x] Documentation

Affected Components

• /.github/workflows - [x] /docs

Motivation

The deploy job cannot start. docker-compose.yml:39 requires POSTGRES_PASSWORD
(${POSTGRES_PASSWORD:?...}, made required upstream in f798130 on 2026-08-16) and the workflow
sets it nowhere in 430 lines, so docker compose up -d db redis opa at line 240 aborts. While it
sits there unable to run, lines 273 and 322 carry the published default database password inside a
postgresql+asyncpg:// URL on a docker run command line, with no allowlist pragma. detect-secrets
1.5.0 reports it as Basic Auth Credentials at line 267 and .secrets.baseline does not allowlist it.

Testing Done

• No tests required, because this is a deletion. git grep -n "pr\.preview" now returns
  nothing, and git grep -rn "preview-deploy" returns only the stale .gitleaks-baseline.json
  fingerprints, which point at .github/workflows/preview-deploy.yml, a path that no longer exists.
  Nothing in the repository depends on them.

Security Considerations

Removes a plaintext database credential from a tracked file. The same literal is printed at
docs/GETTING_STARTED.md:166, so this rotates nothing; it removes one place the value is stored.
The same default credential also remains in git history, so an administrator must rotate it
regardless -- deletion at HEAD is not remediation.

Breaking Changes

• Yes. The deploy-preview, deploy-preview-m365 and teardown-preview labels stop having
  any effect. A required status check named after one of these must be removed by an administrator.

Rollback Plan

• Revert is sufficient. git log --diff-filter=D -- .github/workflows/pr.preview-deploy.yml
  recovers the original.

Caveat (GRC-D03)

Demonstrates policy-decision correctness against fixtures. No live tenant has been
collected, so this is not evidence of any organisation's control posture.

[sh4mbhavi]

Gate output, run against a clean export of this branch and, where a before/after matters, against
main (5bf4ea8).

No file references the deleted workflows:

$ git grep -n "pr\.preview"
(exit 1, no output)

$ git grep -rl "preview-deploy"
.gitleaks-baseline.json

The remaining hit is two historical fingerprints keyed to commit f5f13553, and they name
.github/workflows/preview-deploy.yml -- a path without the pr. prefix that has not existed since
the file was renamed. They are stale either way.

Nothing pushes to a registry any more:

$ git grep -rn "ghcr.io\|build-push-action\|docker push" .github/workflows/
(exit 1, no output)

On main the same command returns 11 hits, all in pr.preview-deploy.yml.

detect-secrets 1.5.0, the version pinned in .pre-commit-config.yaml:

# on main
$ detect-secrets scan .github/workflows/pr.preview-deploy.yml
[('.github/workflows/pr.preview-deploy.yml', 267, 'Basic Auth Credentials')]

# on this branch
$ detect-secrets scan .github/workflows/
files flagged: NONE

.secrets.baseline on main has "results": {}, so nothing was suppressing that finding.

One thing this does not do: pre-commit run detect-secrets --all-files still fails on main and
still fails after this change, on 15 findings in .gitleaks-baseline.json and
backend-api/app/db/seed_dev.py that this pull request does not touch. The claim here is only the
narrow one -- line 267 is gone.

[sh4mbhavi]

Closing: opened prematurely and not ready for review. The changes here are being reworked and will come back as their own pull requests.

[akshitpatel1732]

Is deleting these three workflow files the only way forward?
Hisotry for pr.preview-deploy.yml runs show most jobs being skipped or being aborted with the exception of one failing job (run by me). The step where it failed includes Alembic migrations which might be the cause as at that time, as main had two alembic heads (now resolved).

Can we preserve these workflow files by hard-disabling them, until a solution is devised to make them work while aligning with our stance on security?

Opinions/arguments are welcome. Thanks.

[akshitpatel1732]

Following up on the disable-vs-delete question: disabling the trigger wouldn't actually get us the security benefit, since the hardcoded credential would still sit in a live, tracked file that detect-secrets/Gitleaks would keep flagging - to fix that properly we'd end up rewriting most of the workflow anyway. Given that, and that this is fully recoverable from git history whenever someone has time to rebuild it with real secret-wiring, going with deletion as proposed.

Approving.

[akshitpatel1732]

Hi @sh4mbhavi, could you please resolve the merge conflict so this can be merged safely? Thanks.

[akshitpatel1732]

Verified the resolved diff directly - clean, just the deletions plus the README correction, and the actionlint/secrets-baseline cleanup for the two stale references that landed on main after this branch was cut. Nothing extra came along. Approving.