/clear carries custom title to new session ID, creating duplicate same-named sessions; resume doesn't rehydrate title

Version: 2.1.220 (behavior observed across sessions recorded with 2.1.217–2.1.220), macOS (darwin 25.5.0)

Bug 1: /clear carries the custom title into the new session ID → duplicate same-named sessions

Running /clear inside a session that was previously /renamed rolls over to a new session ID (as expected), but copies the custom-title record as the first line of the new session's jsonl:

{"type":"custom-title","customTitle":"wezterm-tmux-setup","sessionId":"<NEW-session-id>"}

The next conversation — often a completely unrelated topic — is then saved under the old name, so the resume picker shows two sessions with identical names. Every rename-then-clear cycle repeats this, accumulating more duplicates.

Repro

1. Start a session, /rename foo
2. /clear
3. Send any message
4. /resume (or restart and open the picker) — two sessions named "foo"

Expected

/clear should either reset the custom title along with the conversation, or (if title retention is intentional) the picker should disambiguate. Users interpret the title as naming one conversation; a cloned title on an unrelated conversation looks like the session "split".

Bug 2: Resuming the session doesn't rehydrate the custom title

Resuming the cloned session shows no name in the live session UI, even though the jsonl contains multiple custom-title records.

Evidence from the session file: normal turn-ends append the triplet last-prompt, custom-title, mode. The resume-only touch appended just:

{"type":"last-prompt","lastPrompt":"...","leafUuid":"...","sessionId":"..."}
{"type":"permission-mode","permissionMode":"default","sessionId":"..."}

— no custom-title, suggesting the title was never loaded into the resumed process's state.