fix(runtime-host): reconcile interrupted cross-Turn message handoffs

## What happened

A Runtime Host connected from Windows Desktop to a Host running inside WSL failed to become ready after the Host was interrupted during message handoff. Increasing `MAKA_RUNTIME_HOST_ELECTION_DEADLINE_MS` to `120000` did not help.

The startup diagnostic reported:

`SessionMetadataConflictError: Message admission Turn conflict`

The workspace contained a durable message admission whose `turn_id` and `run_id` still referred to the preceding root Turn, while the authoritative `core_root_turn_admissions` record had already committed the same message to the successor Turn. The message content and message identity matched. This is a valid-looking partial handoff state after an interruption, but startup recovery treated it as an unrecoverable conflict.

Expected behavior: startup recovery should reconcile this state idempotently and continue, provided the authoritative root admission proves the same message identity and content. It should still reject genuine message or content conflicts.

## How to reproduce

1. Run Maka Desktop on Windows with its Runtime Host in a WSL environment.
2. Keep a Turn active and submit a steering message.
3. Interrupt or lose the WSL Runtime Host during the transition from the active Turn to the successor Turn.
4. Restart Maka or reconnect the Windows Desktop client to the WSL Host.
5. Observe that the Host remains in `recovering` and the client reports that a Runtime Host was found but did not become ready.
6. Increasing `MAKA_RUNTIME_HOST_ELECTION_DEADLINE_MS` does not resolve the error.

The minimal observed inconsistent state was:

- `message_admissions`: the message pointed to the preceding Turn and was still marked `steering`.
- `core_root_turn_admissions`: the same message was committed to the successor Turn.
- `core_root_source_message_proofs`: the same message identity was present for the successor Turn.

## Environment

- Maka version or commit: `12d3fb933`
- OS: Windows Desktop client connected to Ubuntu WSL Runtime Host
- Surface: Desktop / Runtime Host / WSL
- Node.js: 26.x in the WSL Host environment
- Workspace: default Maka workspace

## Logs, screenshots, or additional context

The relevant recovery path is `packages/runtime-host/src/server/message-coordinator.ts`, which calls `markMessagesHandedOff`, and `packages/storage/src/sqlite-session-metadata-store.ts`, where the Turn mismatch is rejected.

The failure was repaired without deleting workspace data by aligning the stale admission's Turn and Run identity with the authoritative root admission. A backup of `runtime.sqlite` was created before the repair.

This does not appear to be caused by resource exhaustion, networking, or the election deadline. The Windows-to-WSL process boundary may have triggered the interrupted handoff, but the Runtime Host should recover from the resulting durable state.