fix(buddy-bot): point the config at this repository, not ts-starter

.config/buddy-bot.ts still carries name: 'ts-starter' from the template. One string, but it splits the bot's brain: git operations run against the checked-out repo (ts-css) while every GitHub API call goes to stacksjs/ts-starter.

That is what has been opening and closing the same PR ~12 times a day since at least 22 Aug — the last 100 PRs on this repo are all chore(deps): update dependency @types/css-tree to 3.2.0, every one closed.

The loop

1. The check job (cron 5,25,45 * * * *) lists buddy-bot branches with local git — sees buddy-bot/update-major-update-typescss-tree on ts-css
2. It asks the API for open PRs — and gets ts-starter's, which of course has no PR for that branch
3. Branch is in the local set but not the protected set → classified orphaned → deleted with git push origin --delete, which does hit ts-css
4. GitHub auto-closes the PR as a cascade of its head branch vanishing
5. The dependency-update job (cron 0 */2 * * * — exactly the observed 12/day) recreates it, because its existing-PR lookup also queries ts-starter and never sees what it already opened

Two details confirm this rather than "someone keeps rejecting the bump": the closed and head_ref_deleted events share an actor and a timestamp, and the runs log "No obsolete PRs found" — buddy-bot never requested a close.

Why the version matters

buddy-bot 0.10.5 fixes this generically: it overrides a mismatched configured repo from GITHUB_REPOSITORY and warns "Configured repository X does not match the checked-out repository Y". This repo pins 0.9.20 via better-dx@0.2.15, whose resolver early-returns when config supplies both owner and name — so the stale value is used silently. I checked the recent run logs: zero override warnings, consistent with 0.9.20.

Bumping to ≥0.10.5 would also stop the loop, but it masks the wrong name rather than correcting it, and it is a lockfile-wide change. Worth doing separately as hardening.

Deliberately not in this PR

• Ignoring @types/css-tree. packages.ignore is real and would silence this one PR, but it treats the symptom — the next dependency would loop identically — and css-tree: ^3.2.1 is already a dependency, so @types/css-tree@3.x may well be the pairing you want. Your call, not a bug fix.
• strategy: 'patch' / excludeMajor. These do not do what their names suggest in the shipped code — filterUpdatesByStrategy returns true unconditionally for 'patch', and excludeMajor is only consulted on one of three update sources.
• Touching .github/renovate.json. Not causally involved: the orphan test only matches buddy-bot/* branches, so renovate branches can never enter it. The sibling repo has a byte-identical renovate.json with both bots active and a correct repository name, and no loop.

After merging

The next dependency-update run will open the PRs it has been failing to create, and a Dependency Dashboard issue (dashboard.enabled: true). That burst is correct behaviour, not the loop continuing. On the following check run, expect the branch to appear under "Protecting" and zero "Deleted branch … via git" lines.

Two things worth a look separately

• stacksjs/ts-starter may need an audit. This repo's bot has been making authenticated API calls against it for ~100 runs; at minimum it pushed a stray buddy-bot/update-major-update-typescss-tree branch there. I only read one run end to end, so I can't rule out other writes.
• The stale name is template-copied. Other repos seeded from ts-starter may carry it too; a name: 'ts-starter' sweep across the org seems worthwhile.

Typechecks clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F1vnJJiE1mSHcBStFJarNL