ci: gate audit-deps to PRs into main for lib/* workflows

[SnowboardTechie]

Summary

• No tracking issue (came out of a conversation on PR #825; happy to file one retroactively if convention requires).
• Time to review: ~5 minutes

Changes proposed

Add a step-level if: gate to the Audit dependencies step in the four lib/* CI workflows:

• .github/workflows/ci-lib-ts-sdk.yml
• .github/workflows/ci-lib-cli.yml
• .github/workflows/ci-lib-core.yml
• .github/workflows/ci-lib-changelog-emitter.yml

Gate: if: github.base_ref == 'main' || github.ref == 'refs/heads/main'.

Result: audit runs for PRs targeting main (and for any future workflow_call invocation from a main-push context), and is skipped for PRs into HOLD-* and other non-main bases.

Context for reviewers

The problem this fixes. Under the HOLD-* batching strategy, PRs into a HOLD branch can fail audit-deps for advisories the PR author cannot resolve — the fix lives on main and has to land there first, then the HOLD branch rebases. Recent concrete example: PR #825 (Transforms PoC, targets HOLD-transforms) fails on the brace-expansion advisory GHSA-jxxr-4gwj-5jf2, whose fix is part of PR #842 targeting main. PR #825's diff has nothing to do with the advisory; the failure is pure noise to that PR's author.

Why gating at the base-branch boundary is the right shape. The HOLD → main checkpoint PR re-runs full CI, including audit, so any advisory live at merge time is gated at the actionable boundary — the moment someone with a path to action (rebase + pull the fix in) is reviewing the change. Auditing intermediate PRs into HOLD-* shifts noise earlier without shifting the fix earlier.

This is the converse pattern to commit 9d72028 (poetry audit → continue-on-error: true for templates/examples). That commit kept audit running with diagnostic visibility but removed the block. This PR removes both the run and the block on non-main targets — appropriate where running the audit produces signal nobody can act on, rather than signal that's useful as a diagnostic.

Why not extend to other audit-running workflows.

• ci-template-quickstart.yml, ci-template-express-js.yml — JS template workflows have a similar concern; left for a separate change (also touches engines.node and template-specific shape).
• ci-template-fast-api.yml, ci-example-california-api.yml, ci-example-pennsylvania-api.yml — already addressed via continue-on-error: true in 9d72028.
• ci-catalog-validation.yml — catalog PRs target main by design, so the gate would be a no-op.
• ci-website-preview.yml — different concern (deploy preview) and different audit semantics (--level high). Left out of scope.

What I verified.

• All four files have identical gate placement (step-level if: right above run:, with explanatory comment).
• Expression syntax: bare expression form is valid for if: (GitHub auto-evaluates without ${{ }} wrapping); github.base_ref and github.ref are both well-known contexts that are not user-controllable, so this is not in the GitHub Actions injection class.
• Behavior table:

Trigger	base_ref	ref	Audit runs?
PR into main	main	refs/pull/N/merge	Yes
PR into HOLD-transforms	HOLD-transforms	refs/pull/N/merge	No
workflow_call from main-push event	(inherited)	refs/heads/main	Yes
Future push: main trigger	(empty)	refs/heads/main	Yes

Out of scope

• Adding a periodic / scheduled audit on main itself. Today's per-package CIs are pull_request-only; the PR-into-main case still catches advisories at merge time, so a scheduled audit is a separate hardening question.
• Extending the gate to the JS template workflows and ci-website-preview.yml. Same principle applies; different shapes warrant a separate look.