Reset successor-spawn name collision: dedup successor name so make-before-break can spawn past a live same-named predecessor (feedback #57)

Implemented reset successor Solo-name dedup on branch `flower/115-reset-name-dedup` in commit `6ca46242838b1cde32a2b8d337917ef9914bd929` (`Fix reset successor daemon name dedup`, trailer `Brief: #115`). Summary: `DaemonResetService` now marks reset successor spawns with an internal dedup override; `SpawnDaemonBridge` keeps normal spawn name-collision safety intact, but when that internal override is present it chooses the next free Solo process name (`canonical`, then `-2`, `-3`, etc.) before rendering the spawn packet and calling Solo. The hidden override is stripped before packet rendering, and the selected process name is exposed as `agent_name` while `canonical_agent_name` remains available for audit/debug output. Added regression coverage proving `DaemonResetService::startReset()` successfully spawns a successor as `flower-orchestrator-3` while a live `flower-orchestrator` process and existing `flower-orchestrator-2` process are present. Verification: - `~/bin/php artisan test --filter=SpawnDaemonBridgeTest` => passed (8 tests, 54 assertions) - `~/bin/php artisan test --filter=DaemonResetServiceTest` => passed (5 tests, 44 assertions) - `MEILISEARCH_KEY=LARAVEL-HERD ~/bin/php artisan test` => 672 tests; 661 passed, 10 skipped, 1 expected sandbox error: `Tests\Feature\SegmentSessionTest::test_real_anthropic_call_produces_a_segment_when_key_present` failed with `cURL error 6: Could not resolve host: api.anthropic.com` - `~/bin/php ./vendor/bin/pint app/Services/Daemons/SpawnDaemonBridge.php app/Services/Daemons/DaemonResetService.php tests/Feature/Daemons/SpawnDaemonBridgeTest.php` => passed

Promotes flower feedback #57 (kind=bug, status=triaged, ops-corroborated "confirmed real"). Follow-up to Brief #111 (reset execution wiring): #111 shipped daemon_start_reset but the successor spawn collides on the canonical role name, so make-before-break is broken for a canonically-named live daemon. PROBLEM: `SpawnDaemonBridge::agentName()` generates the canonical daemon name (e.g. `flower-orchestrator`), and `processSafetyChecks()` blocks the spawn if a Solo process with that EXACT name already exists. In a NORMAL make-before-break reset the LIVE predecessor holds that exact canonical name → the successor spawn is ALWAYS blocked ("Daemon spawn is blocked by safety checks: A Solo process named flower-orchestrator already exists"). Witnessed live: orchestrator 996's own reset first FAILED on this (daemon 10 audit: reset_failed @ 10:03:21 "successor spawn failed: Daemon spawn is blocked by safety checks") and only proceeded because the leftover inert 969 had been renamed away from the canonical name. FIX (ops-endorsed, lower-risk = option 1): the reset successor spawn should use a DEDUP SUFFIX (e.g. `flower-orchestrator-2` / next-free `-N`) while the predecessor keeps the canonical name; the successor then spawns cleanly ALONGSIDE the live predecessor, and N-closes-O proceeds. OPTIONAL/secondary: rename the successor back to the canonical name AFTER the predecessor is retired to avoid permanent `-N` drift — keep this optional; the core fix is a collision-free successor spawn. (Alternative option 2 — exempt the predecessor-being-reset from the processSafetyChecks collision — is higher-risk; prefer option 1 unless clearly cleaner.) FILES: `app/Services/*` SpawnDaemonBridge (agentName + the reset/successor spawn path), the processSafetyChecks collision logic, and wherever `daemon_start_reset` drives the successor spawn. VERIFY: add a test proving a reset successor spawns SUCCESSFULLY while a Solo process with the canonical name is still live (the exact scenario that currently fails); `php artisan test` green; `./vendor/bin/pint` clean. Live re-dogfood of daemon_start_reset is orchestrator-side, post-merge.