fix(bd): reap stale .beads/issues.jsonl on managed scopes

[scarson]

Closes #2059. Companion to #1968 (which fixed export.auto going forward) and #1930 (empty .beads/dolt/ case).

Summary

• #1968 made export.auto: false canonical so bd doesn't regenerate .beads/issues.jsonl on every write. That fix is correct but only suppresses future exports.
• On long-lived managed cities, a pre-existing 15 MB / 34k-row issues.jsonl from before fix(bd): force export.auto: false in managed config (#1965) #1968 still triggers bd's auto-import-on-write path on every subsequent bd write. The bd subprocess stalls at the 2m timeout re-importing all 34k rows into Dolt before the write completes.
• Symptom: gc mail send / gc sling / gc session new all time out at 2m on these cities. The user-visible workaround is manual rm .beads/issues.jsonl per scope, which is exactly what fix(bd): force export.auto: false in managed config (#1965) #1968 was supposed to eliminate.
• This PR adds the stale-file cleanup as a two-layer defense:
  1. bdStoreFor{City,Rig} (cmd/gc/bd_env.go) — best-effort reap when the scope is gc-managed (steady-state, every store construction).
  2. ensureCanonicalScopeConfigState (cmd/gc/beads_provider_lifecycle.go) — reap when canonicalization actually mutates config (transition-moment cleanup for newly-normalized scopes).
• Plus: tighten bdRuntimeEnv to set BD_EXPORT_AUTO=false on every gc-spawned bd subprocess. Belt to the canonical config's suspenders — covers fresh inits whose config hasn't been canonicalized yet, and short-circuits the export → next-write-import cycle even when an out-of-band caller left a stale JSONL on disk.

Why this is safe

• The reaper only fires when the scope is provably gc-managed:
  • .beads/config.yaml has export.auto: false (steady-state post-fix(bd): force export.auto: false in managed config (#1965) #1968 signal), OR
  • gc.endpoint_origin is one of managed_city, city_canonical, or inherited_city (transitional signal for cities older than fix(bd): force export.auto: false in managed config (#1965) #1968 whose config hasn't been canonicalized yet).
• Rigs that deliberately keep JSONL-based sharing — those that set gc.endpoint_origin: explicit per fix(bd): force export.auto: false in managed config (#1965) #1968's escape hatch — are explicitly not treated as gc-managed, so their issues.jsonl is left alone.
• Unmanaged scopes (no .beads/config.yaml, or config without any gc-managed signal) are also left alone — the reaper is conservative by default.
• All operations are best-effort: os.Stat / os.Remove errors are swallowed because the env-var BD_EXPORT_AUTO=false in bdRuntimeEnv is a second line of defense for gc-initiated calls. A concurrent reader of the JSONL (e.g., a third-party bd-aware tool) won't fail the caller's operation.

Verified locally

samtown (34k beads, 15 MB stale JSONL, dolt server healthy):

command	before	after
gc mail send mayor "..." "..." from rig	120s (timeout)	3.0s
gc mail count	2.5s	1.7s
gc mail read <id>	--	2.2s
gc bd list	0.3s	0.3s
gc bd --rig <r> list	0.3s	0.3s

After the patched binary handles a write, .beads/issues.jsonl does not reappear — confirming the env-var + canonical-config defenses together hold the line.

Testing

• Targeted unit tests (TestBdRuntimeEnvDisablesAutoExport, TestScopeIsGCManaged*, TestReapStaleBdExportJSONL*, TestReadExportAuto*, TestEnsureCanonicalConfigForcesAutoExportOff*) — all pass.
• go vet ./... — clean.
• gofmt -l on touched files — clean.
• golangci-lint run --new-from-rev=main cmd/gc/... internal/beads/contract/... — 0 issues.
• Live end-to-end probe on samtown (numbers above).
• make check — there are pre-existing macOS-specific test flakes on main (TestResolveDoltConnectionTargetManagedCity_EnvOverride fails to bind 127.0.0.2; TestControllerStateMutationRollsBackWhenRefreshFails hangs at 5m) that I reproduce on clean 1c5b6073 before any of my changes. CI on Linux should run cleanly — flagging this for the reviewer rather than papering over it.
• make check-docs — no docs/nav/links touched.
• make test-integration — would appreciate the reviewer's read on whether the integration suite covers the canonicalize-then-write path I added a reaper to.

Checklist

• Linked an issue (bug: pre-existing .beads/issues.jsonl on managed scope still stalls bd writes for 2m after #1968 #2059).
• Added tests for behavior changes.
• Updated docs — none required; the change is internal plumbing with no user-visible CLI or config surface.
• Called out the macOS test-flake caveat above.

Why this is a draft

CONTRIBUTING.md says to discuss in an issue first; #2059 is the issue. Marking as draft pending maintainer triage on:

1. Whether the two-layer defense is the right approach (vs. e.g. a one-shot migration in gc doctor --fix).
2. Whether the gc-managed signal set (export.auto: false OR managed endpoint origins, exclude explicit) matches the project's mental model.
3. Whether a make check-docs / make test-integration confirmation is required before un-drafting.

Happy to iterate on any of the above.