ci(gitleaks): extend the centralized config and move the action to v16

[duckhawk]

Why

.gitleaks.toml declared [extend] useDefault = true, which extends gitleaks' own defaults — not the centralized Deckhouse config. So gitleaks.base.toml never applied here, and neither did the three rules it defines that exist in no default ruleset: werf-secret-key, hashicorp-vault-token, openbao-token. A committed Vault token or werf secret key was invisible.

Pointing [extend] at the base config is exactly what the header of gitleaks.base.toml documents. Measured on a scratch repo holding a Vault token, a 32-hex .werf_secret_key, an h1: checksum and a docs placeholder:

Module config	Rules that fired
useDefault = true (before)	generic-api-key only
useDefault = false + path (after)	hashicorp-vault-token, werf-secret-key

In the second case generic-api-key also disappears — the base allowlist suppresses the checksum, so the whole chain is live.

The action moves @v6 → @v16 because that is what makes the base config exist at all: v6 predates it entirely (no gitleaks/config/ directory, and it greps for an undotted gitleaks.toml no module ships). v16 copies the base config to the repository root, so the relative path resolves. Only the gitleaks action is repinned — build, cve_scan, go_* and deploy keep their own refs.

Verification

Reproduced the v16 layout locally (base config at the repository root, -c .gitleaks.toml, run from the root) and scanned at full history scope across all live refs:

$ gitleaks detect --no-banner -c .gitleaks.toml --source . --log-opts "--remotes=origin --tags"
INF no leaks found

Same result for all 17 storage modules, so re-enabling the centralized rules turns nobody red.

Note

No change is needed in modules-actions itself. The choose-one logic there is deliberate — the base config stays centralized and a module that wants additions must extend it explicitly. This module simply never honoured that contract.

Two caveats worth knowing:

• gitleaks detect -c .gitleaks.toml now fails locally with FTL failed to load extended config, because gitleaks.base.toml only exists inside CI. That is inherent to the documented contract.
• The relative path resolves against the current directory, not the config file's directory, so the scan must run from the repository root. CI does.