v1.36.0: Security Suite scanner config single source of truth

- reusable-secret-leak-check: config resolution (repo-local .betterleaks.toml /
  .github/.betterleaks.toml -> centralized fetch -> built-in), new config-repo /
  config-ref inputs.
- Canonical .betterleaks.toml base; pinact config deduped to the root .pinact.yml;
  betterleaks/default.toml removed; pinact/dependabot.yml drop-in header.
- Scheduled workflow-template pin sync (#100) + pin sync to v1.35.0 (#101).

refactor(secret-leak): delete duplicate betterleaks/default.toml; dep…

…endabot drop-in header (#103)

- Delete betterleaks/default.toml. Its ruleset is now the single canonical
  .betterleaks.toml base; the weekly org audit's one divergence (disabling
  generic-api-key) is expressed as a generated [extend] overlay on the audit
  side. Update the stale "Org default.toml" note in reusable-secret-leak-check.yml
  to name the canonical base. betterleaks/ now holds only the pre-commit example.
- pinact/dependabot.yml: rewrite the header as a drop-in config. The Backstage
  scaffolder now fetches this file into repos, so it should not read as copy-me
  instructions; adoption and merge guidance stay in docs/github-actions-pinning.md.

GATED: merge only after the weekly audit (geolonia-operations) stops fetching
betterleaks/default.toml. Deleting it before that lands would 404 the audit's
config fetch.

refactor(secret-leak): delete duplicate betterleaks/default.toml; dep…

…endabot drop-in header (#103)

- Delete betterleaks/default.toml. Its ruleset is now the single canonical
  .betterleaks.toml base; the weekly org audit's one divergence (disabling
  generic-api-key) is expressed as a generated [extend] overlay on the audit
  side. Update the stale "Org default.toml" note in reusable-secret-leak-check.yml
  to name the canonical base. betterleaks/ now holds only the pre-commit example.
- pinact/dependabot.yml: rewrite the header as a drop-in config. The Backstage
  scaffolder now fetches this file into repos, so it should not read as copy-me
  instructions; adoption and merge guidance stay in docs/github-actions-pinning.md.

GATED: merge only after the weekly audit (geolonia-operations) stops fetching
betterleaks/default.toml. Deleting it before that lands would 404 the audit's
config fetch.

v1.35.0

- betterleaks v1.5.0 -> v1.6.1 (Security Suite scanner) (#99)
- harden sync-team-access workflow template (explicit perms + secrets) (#98)
- github-actions group bump (4 updates) (#97)

chore(betterleaks): bump v1.5.0 -> v1.6.1 (#99)

Update the pinned betterleaks image digest in the reusable Secret Leak
Check workflow and the matching pre-commit example rev.

v1.6.1 highlights:
- Expr replaces CEL as the expression runtime (existing CEL configs
  still accepted for compatibility).
- Faster cold start (lazy regex/tokenizer init) and a smaller binary.
- Rule specificity for more accurate generic-rule suppression.
- Adds a config command; crypto dependency bump.

The org default.toml uses only regex/path allowlists (no CEL/Expr
expressions), so the runtime migration does not affect it.

Digest sha256:7a43a20d... resolved from the v1.6.1 tag on ghcr.io.

feat(techdocs): allow AWS account ID via vars, not just secrets (#95)

Reusable workflows don't auto-inherit secrets (only vars), so the AWS
account ID was the one setting forcing every caller to keep a secrets:
block (or secrets: inherit, which zizmor flags). An account ID is a
non-sensitive identifier, so read it from the vars context too:

  ...|| vars.AWS_ACCOUNT_ID || vars.TECHDOCS_AWS_ACCOUNT_ID

Back-compat: secrets are still tried first, so existing callers are
unaffected. Callers that set the org/repo variable can now drop the
secrets: block entirely (down to permissions: + uses:).

Closes #94

feat(techdocs): allow AWS account ID via vars, not just secrets (#95)

Reusable workflows don't auto-inherit secrets (only vars), so the AWS
account ID was the one setting forcing every caller to keep a secrets:
block (or secrets: inherit, which zizmor flags). An account ID is a
non-sensitive identifier, so read it from the vars context too:

  ...|| vars.AWS_ACCOUNT_ID || vars.TECHDOCS_AWS_ACCOUNT_ID

Back-compat: secrets are still tried first, so existing callers are
unaffected. Callers that set the org/repo variable can now drop the
secrets: block entirely (down to permissions: + uses:).

Closes #94

feat: fail the Security Suite on error-severity findings (TODO 2) (#93)

Previously zizmor was fully warn-only, so a PR could 'pass' the suite with a
zizmor error. Make the report job the single gate: it now exits 1 on any
error-severity condition (a hard-gate fail/error, or a zizmor error-severity
finding), after posting the summary comment so the result stays visible.

- report job: track SUITE_FAILED in the two [!CAUTION] branches, exit 1 at the
  end; update the zizmor callout to say error-severity findings block.
- zizmor step keeps continue-on-error (still emits annotations + counts); the
  report job decides blocking. Warnings/notices (and warn-only pinact) never
  block; bumblebee/betterleaks already block via their own jobs.
- docs: add a 'What blocks a PR' table to security-suite.md.

Note: once released, this blocks any repo that still has a zizmor error
(org-wide) until hardened (see #87 / infra-cdk#152 for the pattern).

feat: fail the Security Suite on error-severity findings (TODO 2) (#93)

Previously zizmor was fully warn-only, so a PR could 'pass' the suite with a
zizmor error. Make the report job the single gate: it now exits 1 on any
error-severity condition (a hard-gate fail/error, or a zizmor error-severity
finding), after posting the summary comment so the result stays visible.

- report job: track SUITE_FAILED in the two [!CAUTION] branches, exit 1 at the
  end; update the zizmor callout to say error-severity findings block.
- zizmor step keeps continue-on-error (still emits annotations + counts); the
  report job decides blocking. Warnings/notices (and warn-only pinact) never
  block; bumblebee/betterleaks already block via their own jobs.
- docs: add a 'What blocks a PR' table to security-suite.md.

Note: once released, this blocks any repo that still has a zizmor error
(org-wide) until hardened (see #87 / infra-cdk#152 for the pattern).

fix: float suite refs on @v1 + keep v1 lightweight + document the rea…

…l root cause (TODO 1) (#92)

The org-wide Security Suite outage (v1.27-v1.31) was NOT caused by floating
reusable refs (that was a red herring). Root cause: the `v1` tag became an
ANNOTATED tag object (my `git tag -a` releases got copied into v1 by the
release workflow), and the ruleset 'require workflows' injector cannot resolve
an annotated v1 -> it silently produces no run and the required check hangs at
'Expected' forever. Fixed live by recreating v1 lightweight.

This restores the no-treadmill floating setup and guards against recurrence:

- security-suite.yml + reusable-security-suite.yml: revert reusable refs to @v1
  (floating is fine; the .pinact.yml + zizmor.yml @v1 exemptions cover them).
- reusable-release-auto-on-tag.yml: peel moved tags to the commit
  (git tag -f v1 "$TAG^{commit}") so v1/minor are ALWAYS lightweight, even if
  a release tag is annotated.
- release-auto-on-tag.yml: float the caller on @v1 so it picks up the peel fix.
- docs/workflows/security-suite.md (new) + workflows.md callout + mkdocs nav +
  reusable_workflows Serena memory: document that v1 MUST be lightweight, the
  single-release upgrade flow, post-release verification, and keep-.github-out-
  of-targets. Corrects the earlier (wrong) 'SHA-pin the whole tree' guidance.

Supersedes #91 (which misattributed the cause to reusable refs).