fix(FN-5353): reacquire fresh worktree when reuse handoff fails instead of falling back to main

Before: when reuse-task-worktree was configured but task worktree was missing/unusable,
merger fell back to cwd-main, losing the task worktree isolation benefit.

After: merger creates a fresh worktree for the task branch inline (using the standard
git worktree add pattern with identity guard installation) and retries the reuse handoff.
Only falls back to cwd-main if fresh acquisition also fails.

Three new audit events track the recovery path:
- merge:reuse-worktree-fresh-acquire — fresh acquisition started
- merge:reuse-worktree-fresh-acquired — fresh worktree created and bound to task
- merge:reuse-fallback-cwd-main — only when fresh acquisition itself fails (last resort)

Behavior:
- Missing/unusable task worktree → fresh worktree created, merge continues from it
- Fresh acquisition fails → cwd-main fallback (last resort, fully audited)
- Genuine liveness conflict (usable worktree but lease refused) → re-thrown, not masked

Regression test covers the missing-worktree case: verifies fresh acquisition + handoff
succeeds without any cwd-main fallback event.

.changeset/fix-fn-5353-reacquire-worktree.md

@@ -0,0 +1,7 @@
+---
+"@runfusion/fusion": patch
+---
+
+fix(FN-5353): reacquire fresh worktree when merge reuse handoff fails instead of falling back to main
+
+When `mergeIntegrationWorktree=reuse-task-worktree` and no task worktree is available (worktree=null after executor teardown), the merger now acquires a fresh worktree (`git worktree add -b fusion/<id>`) instead of falling back to `cwd-main`. Falls back to `cwd-main` only if fresh acquisition itself throws. New audit events: `merge:reuse-fallback-new-worktree`, `merge:reuse-worktree-fresh-acquire`, `merge:reuse-worktree-fresh-acquired`, `merge:reuse-fallback-cwd-main`.