feat(cli): add thread clear-name to remove a custom thread title (1600)

[ousamabenyounes]

Summary

Fix 1600

Issue 1600 asks for full rename UX on threads: set a custom title, and remove it back to (unnamed). The set side already shipped as deepseek thread set-name <id> <name>, but the inverse was missing — users who wanted to drop a no-longer-relevant title had to either edit the SQLite store by hand or write a placeholder string.

This PR adds deepseek thread clear-name <id>, mirroring the existing SetName arm in run_thread_command:

• Lookup the thread (get_thread), error out cleanly when the ID does not exist (thread not found: <id>).
• Set name = None, refresh updated_at, upsert.
• Print cleared name for <id> so it stays distinguishable from the renamed <id> line emitted by set-name.

No state-store changes are needed: upsert_thread already accepts name: None, and thread list already prints (unnamed) when the field is empty.

The TUI session-picker key shortcut and deepseek sessions (older alias) display, also mentioned in 1600, are intentionally not in scope for this PR — they touch separate surfaces (picker UI + thread/session display layers) and the harvest model in CONTRIBUTING.md prefers single-purpose contributions.

Testing

• cargo test -p deepseek-tui-cli — 65/65 pass, including a new parse_ok(&["deepseek", "thread", "clear-name", "thread-7"]) assertion in parses_thread_command_matrix and a new clear-name entry in subcommand_help_surfaces_are_stable.
• cargo fmt --all -- --check — clean
• cargo clippy -p deepseek-tui-cli --all-targets --all-features — no new warnings

TDD verification (RED → GREEN)

RED — production change reverted (ThreadCommand::ClearName variant + matching run_thread_command arm + parser-matrix matches! removed), only the snapshot list entry kept on the test side:

running 1 test
test tests::subcommand_help_surfaces_are_stable ... FAILED

---- tests::subcommand_help_surfaces_are_stable stdout ----
thread 'tests::subcommand_help_surfaces_are_stable' panicked at crates/cli/src/lib.rs:2731:17:
expected help for `thread` to include `clear-name`

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 64 filtered out

GREEN — production change restored (HEAD of this branch):

test tests::parses_thread_command_matrix ... ok
test tests::subcommand_help_surfaces_are_stable ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 63 filtered out

The snapshot test pins clap's help surface (variant must be wired in for clear-name to appear); the parser-matrix test pins the dispatch shape. The run_thread_command arm itself mirrors SetName line-for-line except for name = None, so it is visually reviewable rather than RED/GREEN-tested.

Checklist

• Updated docs or comments as needed (new variant has a doc comment explaining the (unnamed) round-trip)
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes — n/a, CLI-only change

Files changed

File	Change
crates/cli/src/lib.rs	New ThreadCommand::ClearName { thread_id } variant, matching run_thread_command arm, parser-matrix assertion, snapshot help update

[gemini-code-assist]

Code Review

This pull request introduces a new clear-name subcommand to the thread management CLI, allowing users to remove a custom name from a thread. The changes include adding the ClearName variant to the ThreadCommand enum, implementing the logic to reset the thread name and update the timestamp in run_thread_command, and adding corresponding unit tests for command parsing. I have no feedback to provide as there were no review comments to evaluate.

[Hmbown]

Thanks for the focused CLI round-trip patch. This is useful and scoped, but I am not taking it into v0.8.42 stabilization because it has only GitGuardian on this PR and the release branch is already narrowed to the stream/RLM/handle_read/help fixes.

Leaving it open for the next maintenance pass. The natural review path is current-branch CI plus a focused cargo test -p codewhale-cli thread --locked / parser-help check under the current crate names, then decide whether issue #1600 is fully covered or whether TUI picker/session display still needs a separate follow-up.