chore(deps): update fro-bot/agent to v0.107.1

[marcusrbrown]

Moves all four action pins from v0.107.0 to v0.107.1.

That release fixes the session-cache failure this repository has hit before: a restored cache entry large or corrupt enough to push bootstrap past its budget caused every run to fail, skip pruning, and re-save the same poisoned cache. The recovery was manually purging every opencode-storage-* entry.

The fix is not what I would have guessed. Pruning is still gated on bootstrap success — instead, restored session databases are now checkpointed and repaired before bootstrap, and structurally corrupt database families are cleaned before retrying. A poisoned cache therefore self-heals on the next run, and the manual purge is no longer a required recovery step.

Two related changes ride along:

• session-retention now actually reaches the pruning configuration. It was previously parsed, validated, and logged but never read, so setting it did nothing.
• The bootstrap timeout is configurable, default still 5000 ms, clamped at 120 s. Distinct from the existing timeout input, which remains execution-only.

Neither input needs to be set here — the defaults are what we already rely on.

Renovate hasn't proposed this bump despite bfra-me/.github already running v0.107.1, so discovery works there but not here. Worth a look separately; it echoes the harness-release visibility problem in fro-bot/agent#1492, though that one is fixed and all harness builds are correctly marked prerelease.

One documentation inaccuracy upstream, not fixed here: action.yaml describes skip-cache as skipping restore, but it disables cache save as well. We don't set it.

Pins updated in fro-bot.yaml, survey-repo.yaml, capture-learnings.yaml, and capture-patterns.yaml. Verified the old SHA appears nowhere in the repository. pnpm check-types, pnpm lint, and pnpm test pass: 2846 tests, 3 todo.

[fro-bot]

Four identical pin bumps, SHA-pinned with version comments intact. I verified the supply-chain claim rather than trusting the comment:

• e6b620bd51ae76e18cfe660d3aab490d29390eda resolves to exactly refs/tags/v0.107.1 in fro-bot/agent (checked via the git ref API, not the release page).
• The release is real: draft: false, prerelease: false, published 2026-09-02, target_commitish: release.
• No live v0.107.0 pin survives anywhere in .github/workflows/. All four occurrences of the new SHA are the four intended lines.
• All four workflows still parse; job counts unchanged (1/2/1/1).

That verification matters more than usual here because survey-repo.yaml hands this action FRO_BOT_POLL_PAT and OPENCODE_AUTH_JSON. A pin bump on a step holding those credentials is a trust transfer, not a version string.

Verdict: PASS

Blocking issues

None.

Non-blocking concerns

1. The Renovate "discovery" mystery is not a mystery, and the answer is in this repo. — .github/renovate.json5:6-11

The description says discovery "works there but not here" and files it as worth a separate look. It's already answered in your own config:

{
  description: 'Disable patch updates except for select dependencies.',
  matchUpdateTypes: ['patch'],
  matchPackageNames: ['!python', '!typescript'],
  enabled: false,
}

v0.107.0 → v0.107.1 is a patch. Renovate saw it and did exactly what it was told. Nothing is broken; the rule is doing its job with more reach than it was probably scoped for.

Impact: every fro-bot/agent patch release now requires a hand-cut PR like this one, indefinitely. That's a standing manual dependency on someone noticing — and as the next point shows, agent patches are not always cosmetic. The remediation is a targeted rule, not a policy reversal:

{
  description: 'Allow patch updates for the agent harness',
  matchPackageNames: ['fro-bot/agent'],
  matchUpdateTypes: ['patch'],
  enabled: true,
}

Out of scope for this PR — but retire the "worth a look separately" framing, because the finding is already made.

2. This patch carries a redaction-bypass fix the description doesn't mention.

The changelog leads with the cache trap, but #1513 is the one that should move your merge urgency. An @octokit/types 16→17 bump began modelling repository id as number | bigint, and databaseId is a key in the operator redaction deny list. Set<number>.has(bigint) is always false — so a repository that was supposed to be redacted could silently stop being denied.

In a repo whose stated invariant is public-only disclosure, and which runs check-private-leak.yaml as a dedicated gate, a deny-list that fails open is the exact failure this org is built to prevent. A guard that returns false for the wrong reason isn't a guard, it's a ghost standing where the guard used to be. Merge this rather than letting it sit.

3. Minor accuracy nit on the description, not the diff.

"Verified the old SHA appears nowhere in the repository" is broader than what holds. 26fdb0b5... still appears at knowledge/wiki/repos/marcusrbrown--marcusrbrown-com.md:257, as a dated historical record of a different repo's pin. Leaving it is correct — the wiki records what was true on 2026-08-31, and rewriting history there would be the actual defect. The claim just needs the qualifier "no live pin," which is the version I confirmed.

Missing tests

None required. No behavior in this repository changed — this is a reference update with no unit-testable surface here. The uses: fro-bot/agent@<sha> shape is already covered generically by the pin-validation suite in scripts/reconcile-repos.test.ts (including the fro-bot/agent-fork and not-fro-bot/agent typo-squat rejections), and those assertions are SHA-agnostic, so they neither needed updating nor silently stopped covering anything.

Per the prior learning on untested seams (docs/solutions/best-practices/test-the-integration-seam-not-the-endpoints-2026-07-06.md): the real seam here is action-resolution at runtime, which no unit test can walk. I substituted the only meaningful check available — resolving the pinned SHA against the upstream tag ref directly. That passed.

Risk assessment

LOW.

Mechanically minimal: four single-token changes, no permission blocks touched, no input surface changed, no new secrets exposed. The two new upstream inputs (session-retention reaching the pruning path, configurable bootstrap timeout) are correctly left unset — defaults are unchanged at 5000 ms, so behavior here is identical minus the bugs.

The residual risk is inherent to any pin bump: you are trusting one upstream commit. That trust is as verified as it can be from this side — tag→SHA exact match, non-prerelease, published release, and the diff is confined to the four call sites. Downside if v0.107.1 regresses is a failing agent run, which is now less sticky than before, since the cache-trap fix is precisely what stops a bad run from poisoning the next one.

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/.github
Run ID	33704001868
Cache	hit
Session	ses_f9b1ac778ffetCAi80USLYkGFr