docs(renovate): correct the global-config comment to state the input is inert

[fro-bot]

The comment above global-config in .github/workflows/renovate.yaml claimed a scoping guarantee the control plane does not have:

# Disable autodiscover — cross-repo dispatch is handled by dispatch-renovate.yaml.
# This workflow should only run Renovate for this repository.
global-config: '{"autodiscover": false}'

The input is discarded on every run, including the green ones. It has never once done what the comment says.

Two independent upstream causes

Both verified 2026-09-20 against the currently pinned bfra-me/.github@5486c68 (v4.30.0) -> bfra-me/renovate-action@78e446d (10.42.1).

1. The value never survives the shell. action.yaml:220 interpolates it textually into a double-quoted assignment:

user_global_config="${{ env.global_config }}"

That is substitution, not expansion. {"autodiscover": false} gets its own quotes eaten before jq sees it, validation fails, and the step logs an error and then continues:

Error: Invalid JSON syntax in user global-config
Warning: User global-config is not valid JSON, falling back to base config

Exit 0. The action already binds the value as an env: var at line 75 — it just doesn't use it. The upstream fix is user_global_config="$global_config".

2. Even if it parsed, it would lose. The reusable workflow derives autodiscover from the repository name and passes it as an explicit action input:

AUTODISCOVER: ${{ github.event.repository.name == '.github' && ... && github.ref == 'refs/heads/main' }}
...
autodiscover: ${{ steps.prepare.outputs.autodiscover }}

This repo is literally named .github, so autodiscover is forced on for schedule and dispatch runs against main, whatever global config says.

Observable net effect: run 35487227927 (main, 2026-09-20) emits the fallback warning and sweeps fro-bot/fro-bot.github.io and fro-bot/systematic — org repos absent from metadata/renovate.yaml's with-renovate list, and therefore not excluded by the negative autodiscover filter.

The bug survived 10.39.0 -> 10.42.1, so it is not transient.

What this PR changes

The comment. Nothing else.

Parsed YAML is identical before and after — verified by parsing both revisions and comparing the resulting objects:

parsed YAML identical: true

No executable change, no behavior change, no guard weakened, no version touched.

Why the comment and not the bug

The bug is upstream in two repositories. Neither is fixable from here, and both candidate local workarounds are worse than the defect:

• Escaping the JSON would ride a specific upstream quoting bug and break the moment upstream switches to env-var indirection.
• Deleting the input erases the declared intent that an upstream fix would restore, and silently accepts a sweep scope nobody chose.

So the input stays and the comment stops lying. A stale comment asserting a false isolation property is the exact failure mode flagged in docs/solutions/workflow-issues/required-github-token-for-agent-steps-2026-06-22.md — keep the comments honest about the mechanism, because a stale comment documents a false guarantee for the next reviewer. This one had been documenting a false guarantee for months.

Follow-up, not in this PR

• Upstream issue on bfra-me/renovate-action for the quoting bug.
• Upstream issue on bfra-me/.github for the unconditional .github-name autodiscover.
• Fleet check: every consumer of that reusable workflow passing global-config is silently running on base config.

Verification

pnpm bootstrap    OK
pnpm check-types  OK
pnpm lint         OK
pnpm test         OK   79 files | 3687 passed | 3 todo

The finding is resolved when a Renovate run log contains no Invalid JSON syntax in user global-config and its sweep names only fro-bot/.github. This PR does not achieve that and does not claim to — it makes the gap legible until upstream closes it.

🤖 Generated by Fro Bot · run 35488760839