bd init leaves issue_prefix uncommitted in config table (same pattern as #3028/PR#3052)

[GraemeF]

Bug

bd init writes issue_prefix to the Dolt config table but never commits it, leaving the row permanently orphaned in the working set. This is the same class of bug as #3028 (fixed for remember/forget/config set by PR #3052) — the bootstrap path was not covered.

Root cause

cmd/bd/bootstrap.go (executeInitAction / executeRestoreAction / executeJSONLImportAction) does:

if err := s.SetConfig(ctx, "issue_prefix", prefix); err != nil { ... }
if err := s.Commit(ctx, "bd bootstrap"); err != nil { ... }

But DoltStore.Commit() at internal/storage/dolt/store.go:1472 explicitly excludes the config table with a comment citing GH#2455 ("skip config to avoid sweeping up stale issue_prefix changes"). So the SetConfig write is never committed.

All three bootstrap paths (lines 391/394, 418/421, 449/452) have the same issue.

Why it accumulates

Commit() is the normal auto-commit path used by bd create, bd update, bd close, etc. Because it skips config, the orphaned issue_prefix row sits in the working set forever. bd doctor reports it as "Dolt Status: config modified"; bd vc status reports clean (it only considers staged); bd dolt pull fails with "cannot merge with uncommitted changes" with no indication that config is the culprit.

My repro

Fresh bd init on 2026-04-09 (bd 1.0.0). First suspicious symptom noticed today on bd dolt pull. dolt_diff_config showed the orphaned row had been sitting since init:

```
bd sql "SELECT COUNT(*) FROM config AS OF 'HEAD'"
-- 10 rows (compaction defaults + schema_version)

bd sql "SELECT COUNT() FROM config"
-- 17 rows (HEAD + issue_prefix + 6 kv.memory. entries)
```

The 6 kv.memory.* were from bd remember calls made before PR #3052 shipped to this machine — those are presumably fixed going forward. The issue_prefix one keeps reappearing on every fresh init.

Workaround: bd sql \"CALL DOLT_COMMIT('-Am', 'cleanup')\" clears it.

Suggested fix

Use CommitWithConfig or CommitPending in the bootstrap paths instead of Commit, matching the pattern introduced by PR #3052:

```go
if err := s.CommitWithConfig(ctx, "bd bootstrap"); err != nil { ... }
```

Secondary UX bug

Even after config is committed, bd dolt pull's error message ("cannot merge with uncommitted changes") doesn't say which table is dirty or suggest the -Am force-commit path. bd vc commit reports "Created commit" without actually committing the offending table (because it inherits Commit()'s config exclusion), misleading users into thinking they've resolved the state.

Ideal: bd dolt pull should either (a) surface the table name and a concrete recovery command, or (b) offer a --include-config / --force-commit flag that commits orphaned config writes before merging.

Version

• bd: 1.0.0 (latest per bd doctor)
• dolt: bundled server mode
• Backend: per-project Dolt, auto-commit on