fix: clear restored leases and release run reservations before completion

[crypt0rr]

What changes

• Restore clears copied leases. The shared restore staging path (stageRestore) deletes the daemon_lease row and all job_leases rows copied from the backup. This runs in the same transaction as the pending-delivery policy, so restore --dry-run does the same in its private copy.
  • The destination's own live-daemon check (refuseActiveDaemon) and the sidecar refusals are unchanged.
  • Backup output is unchanged and never touches the live database.
• Manual runs release their reservation before the completion callback. App.StartManagedRun releases the job's run reservation with CompareAndDelete after the run returns and before done runs.
  • A deferred CompareAndDelete still covers a panic.
  • Comparing the stored value keeps an earlier run from removing a newer run's reservation.
  • The deferred release runs before wg.Done, so StopRun waits for it.
• The real-stack browser test retries Scan now on 409. A clickScanNow helper waits for the POST /api/v1/jobs/<id>/run response and retries only on 409, because the scan row is saved before the run releases its job lease.
• README and SECURITY.md describe the restore lease behavior.

Why

• [P3] Restoring a backup taken from a running daemon blocks the restored daemon and repeat restores for two minutes #821: a backup taken from a running daemon carries that daemon's fresh heartbeat.
  • After a restore, the new daemon refused to start with "another EdgeWatch daemon holds the database lease". Under Compose it restart-looped for up to two minutes.
  • A repeat restore onto the stopped destination was refused as if a daemon were active.
  • No process runs on a restored copy, so every copied lease is stale. That includes CLI scan leases, which would otherwise keep a job busy until they expire.
• [P3] Scan now right after a manual scan completes returns 409 because the run reservation outlives the completion broadcast #826: the web completion callback broadcasts scan.completed, and the console then re-enables Scan now.
  • The reservation was held until that callback returned, so an immediate click got 409 even though the scan had finished.
  • The same timing failed TestConsoleBaselineChangeIncidentFlow on fix(store): keep live SQLite sidecars and refuse unsafe writable opens #818 and the real-stack browser test on iphone-13 on fix(scanner): keep scan coverage and probe budgets truthful #819.

Validation

• Store regression tests:
  • TestRestoreClearsLeasesCopiedFromLiveDaemonBackup failed before with restore refused because an EdgeWatch daemon is active (owner old-daemon …). It also checks that a restore over a destination with a live daemon is still refused.
  • TestRestoreLeaseCleanupFailureLeavesDestinationUnchanged
  • TestClearRestoredLeasesSkipsMissingTablesAndReportsErrors
• App regression tests:
  • TestStartManagedRunAcceptsNextRunFromCompletionCallback failed before with job is already running.
  • TestManagedRunReleaseKeepsNewerReservation failed before because the newer reservation was removed.
  • TestManagedRunReleasesReservationAfterPanic
• Checks:
  • go vet ./...
  • go test -race for internal/store, internal/app and internal/web
  • pinned golangci-lint with --new-from-rev=origin/main: 0 issues
  • Go changed-line coverage: 100%
• Frontend and browser checks:
  • npm run lint, npm run build and npm run test:coverage
  • npm run test:e2e: both real-stack tests pass on all four browser projects.
• After rebasing onto schema 48, the build, vet and the targeted restore and run-reservation tests pass again.

Closes #821
Closes #826