ci(deps): Dependabot grouping + /tests/git-sync coverage (#1243)

[vybe]

Fixes #1243 (canonical landing — dependabot.yml is read from the default branch, so the grouping/coverage changes only take effect once this lands on main).

Companion PR required: the workflow runs from the PR's base branch, and the high-volume version-update PRs target dev. A twin PR to dev carries the same two files — both must land for full coverage (main = security PRs + config-read; dev = version-update PRs).

What this does

Layer 1 — .github/workflows/dependabot-auto-merge.yml

• Auto-merges Dependabot semver patch/minor only (every ecosystem incl. github-actions & dev-deps). All majors held for human review.
• Substantive gate is CI: waits for build + every pytest check to be green in-workflow (path-filtered PRs with neither check fall back to the required CodeQL gate via --auto).
• Branch protection requires 1 approval with enforce_admins: true and the Actions GITHUB_TOKEN can't supply a counting approval — so a machine PAT (DEPENDABOT_AUTOMERGE_TOKEN, a Dependabot secret) approves eligible green PRs, then gh pr merge --auto --squash.

Layer 2 — .github/dependabot.yml

• Group github-actions bumps into one weekly PR (was one PR per action).
• Cover the previously-uncovered /tests/git-sync npm dir — source of esbuild alert fix: Guard stream-json parser against non-dict JSON lines (#151) #152.

Activation (manual — required, only a human can do it)

1. Create a fine-grained PAT (dedicated machine account recommended) on Abilityai/trinity with Pull requests: read/write + Contents: read/write.
2. gh secret set DEPENDABOT_AUTOMERGE_TOKEN --app dependabot --repo Abilityai/trinity (Dependabot store, NOT Actions).
3. Repo allow_auto_merge enabled (done out-of-band).

Until the secret exists the final step no-ops with a warning — nothing merges.

Not in this PR (Layer 3, follow-up)

Weekly triage process + main → dev back-merge so security PRs (which land on main) don't strand dev. Tracked in #1243.

[dolho]

Concern: this enables zero-touch merges directly to main

The auto-merge workflow has no base-branch guard (on: pull_request + if: actor == dependabot[bot]), so once this lands on main it will auto-approve + --auto --squash any eligible Dependabot PR targeting main.

Routine version updates can't reach main (every ecosystem in dependabot.yml pins target-branch: dev, and src/cli isn't listed). But GitHub security updates ignore target-branch and land on the default branch = main — those are exactly the PRs this would merge unattended.

Why that's risky in this repo:

1. Breaks the one-way dev → main flow. A security PR merged straight to main is a main-only commit not in dev → the next release PR diverges/conflicts, or the fix is missing from dev and silently regresses. Auto-merge provides no back-merge.
2. No human on the production branch for dep changes (supply-chain / transitive-break risk on a public, credential-handling product).
3. Unattended publish: a security update touching src/cli/** would trip publish-cli.yml → a real PyPI publish with nobody in the loop.
4. Shallow CI gate: for a pure dep bump, build/pytest are often path-filtered out → the wait step exit 0s and merges on required checks only (CodeQL), which won't catch a runtime regression.

Suggested options (best first):

1. Keep auto-approve + CI on main, but don't auto-merge there — let a human click merge for the (rare) security PRs. Drop the gh pr merge --auto step when base.ref == 'main'.
2. If fast security patching is the goal: restrict to security-updates only, require the full test suite (no path-filter escape), exclude publish-triggering paths (src/cli), and add a scheduled main → dev back-merge.
3. Simplest provable fix — make the workflow dev-only:

   jobs:
     auto-merge:
       if: ${{ github.actor == 'dependabot[bot]' && github.event.pull_request.base.ref == 'dev' }}

   (and accept that main security PRs are reviewed manually)

#1245 (→ dev) looks good to me as-is; dev is the right home for zero-touch dep merges (it also has the deploy-dev safety net and still passes through the release gate before prod).

[vybe]

Confirmed and adopted — thank you, this is a sharp catch. We traced publish-cli.yml and the src/cli manifest to verify the publish risk wasn't hypothetical:

• publish-cli.yml triggers on push: branches: [main], paths: ['src/cli/**'] (not only cli-v* tags), and
• on a non-tag push it auto-increments the patch from the latest cli-v* tag and publishes to PyPI if that version doesn't already exist.

So a security PR for a vulnerable dep in src/cli/pyproject.toml, auto-merged to main, would cut and publish a new trinity-cli release to PyPI with no human in the loop. Not a trade worth making.

Decision (option 3): auto-merge is dev-only.

• This PR (ci(deps): Dependabot grouping + /tests/git-sync coverage (#1243) #1244) is now dependabot.yml-only — grouping + /tests/git-sync coverage. No auto-merge workflow lands on main.
• ci(deps): Dependabot auto-merge for low-risk PRs + grouping (dev) (#1243) #1245 (→ dev) gains a base.ref == 'dev' job guard so the workflow is structurally incapable of acting on main, even after a release carries the file there.
• main security PRs are merged by a human; everything auto-merged on dev still passes the human release gate before prod.

Your risks #1 (back-merge) and #2 (security-only + full-suite + exclude src/cli) are captured as the Layer 3 follow-up in #1243 if we ever want fast unattended security patching to main.