fix(daemon): make daemon start idempotent

[Harrison97]

Summary

Make bd daemon start idempotent - when a compatible daemon is already running, exit successfully (code 0) instead of failing (code 1).

Problem

During gt reload, there's a race condition where something auto-starts the bd daemon between the killall and start phases. This causes "already running" errors even though the reload should succeed.

The root cause is that bd auto-starts daemons when running any command. A hook, background task, or any bd command can trigger this.

Solution

If the daemon is already running AND healthy AND version-compatible, print a message and exit 0 instead of exit 1. This makes the operation idempotent.

$ bd daemon start
Starting bd daemon...
$ bd daemon start  
Daemon already running (PID 12345, version 0.49.0)  # exit 0, not exit 1

Test plan

• Build bd with fix
• Verify bd daemon start returns exit 0 when daemon already running
• Verify gt reload completes successfully without race condition errors

Fixes: #1331

🤖 Generated with Claude Code

[citadelgrad]

Thanks for the PR! One issue found during review.

What's Good

• ✅ The daemon idempotency change is correct and minimal
• ✅ Good verbose logging in resolveExternalDependencies for debugging
• ✅ Graceful failure - returns nil on errors so local deps still work
• ✅ Proper resource cleanup (closes DB connections)

Hopefully not too many notifications. I was experimenting with gh cli and making mistakes.

[citadelgrad]

Uses wrong database initialization pattern

The PR uses raw sqlite.New() but other cross-rig commands use factory.NewFromConfig() which respects backend configuration:

// Current (inconsistent):
targetDBPath := filepath.Join(targetBeadsDir, "beads.db")
targetStore, err := sqlite.New(ctx, targetDBPath)

// Established pattern (from create.go:947, move.go, refile.go):
targetStore, err := factory.NewFromConfig(ctx, targetBeadsDir)

Using factory.NewFromConfig ensures correct backend selection and consistent behavior with other cross-rig operations.

[citadelgrad]

Performance consideration in resolveExternalDependencies

The function opens a new database connection for each external dependency. If multiple deps reference the same project, this is inefficient:

  // Current: opens/closes DB per dependency
  for _, dep := range deps {
      targetStore, err := sqlite.New(ctx, targetDBPath)  // Opens here
      issue, err := targetStore.GetIssue(ctx, targetID)
      _ = targetStore.Close()  // Closes here
  }

Consider grouping by project first, then batch-fetching:

// Group deps by project, open each DB once
  depsByProject := groupByProject(deps)
  for project, projectDeps := range depsByProject {
      targetStore := openOnce(project)
      defer targetStore.Close()
      for _, dep := range projectDeps {
          // fetch issues
      }
  }