Handle concurrent default-group creation during startup

Summary

thv startup can fail when multiple CLI processes initialize the default group concurrently. This is reproducible in the core E2E shard, which runs Ginkgo with PROCS=4.

Reproduction

Start four processes concurrently against the same fresh state directory:

for i in 1 2 3 4; do
  ./bin/thv --help &
done
wait

With a fresh shared XDG state directory, one process creates the default group and another process exits with:

failed to ensure default group exists
group already exists: default

Root cause

cmd/thv/main.go runs migration.EnsureDefaultGroupExists() for --help because --help is not classified as informational. pkg/migration/migration.go performs an Exists check followed by Create. Concurrent processes can all observe that the group is absent; one wins creation and the others receive groups.ErrGroupAlreadyExists. That expected race is returned as a fatal startup error.

The E2E helper then reports this misleadingly as thv binary not available because it only preserves the command error and discards stderr (test/e2e/helpers.go:367-372).

Expected behavior

If another process creates the default group first, startup should treat groups.ErrGroupAlreadyExists as success and continue.

Suggested validation

Add a regression test that invokes concurrent default-group initialization against a shared local store and verifies all callers succeed. Also preserve stderr in CheckTHVBinaryAvailable so startup failures are diagnosable.

Related PR: #6350

Start with cmd/thv/main.go and pkg/migration/migration.go to trace default-group initialization, then inspect test/e2e/helpers.go:367-372 for stderr handling. Add the suggested concurrent shared-store regression test, treat groups.ErrGroupAlreadyExists as success, and preserve stderr so CheckTHVBinaryAvailable reports startup failures. Validate with the core E2E shard or four concurrent ./bin/thv --help processes.