init --reinit-local preflight: count errors silently skip the destroy confirmation, and the counted DB can differ from the gated DB

Two related pre-existing hazards in the bd init --reinit-local destroy-confirmation preflight, found while reviewing #5310 (both independent of that PR).

1. countExistingIssues errors silently skip the destroy confirmation.

cmd/bd/init.go:800:

if count, err := countExistingIssues(prefix); err == nil && count > 0 {

Any error from countExistingIssues - including its own 5-second context timeout (init.go:2660) on a large or slow database - makes the whole safeguard block a no-op: no count shown, no --destroy-token demanded, no interactive confirmation. The databases most likely to time out the count are exactly the ones with the most issues to lose. An error here should refuse and report, not fall through to the destructive path.

2. The preflight counts a database the gate may not cover.

countExistingIssues resolves its workspace via walk-up (beads.FindBeadsDir(), init.go:2647-2654), while the reinit gate keys on beadsDirForInit, which resolves via GetWorktreeFallbackBeadsDir() + redirect-following (init.go:951-958). When the two disagree - nested workspaces, worktree fallback, redirects - the confirmation can display a count from one database while the destroy applies to another: either an alarming count for a DB that is not being touched, or (worse) 0 issues confidence while the actual target has data.

Suggested direction: make the preflight resolve through the same beadsDirForInit value the gate uses, and treat a count error as a refusal (exit with an actionable message) rather than a skip. Happy to send a PR if the direction is agreed.

claude-fable-5-high on behalf of maphew