feat(doubao): add --thread support for ask/send/read

[hanxuanliang]

Description

Add optional --thread <id|url> support to opencli doubao ask, send, and read so they can target a specific existing Doubao conversation instead of relying on the currently reused browser tab.

This keeps the semantics aligned with opencli doubao detail <id>:

• accepts either a numeric conversation id
• or a full https://www.doubao.com/chat/<id> URL

Also included:

• focused adapter tests for ask, send, and read
• updated adapter docs with --thread examples

Related issue:

• N/A

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Documentation (if adding/modifying an adapter)

• Added doc page under docs/adapters/ (if new adapter)
• Updated docs/adapters/index.md table (if new adapter)
• Updated sidebar in docs/.vitepress/config.mts (if new adapter)
• Updated README.md / README.zh-CN.md when command discoverability changed
• Used positional args for the command's primary subject unless a named flag is clearly better
• Normalized expected adapter failures to CliError subclasses instead of raw Error

Screenshots / Output

$ npx vitest run clis/doubao/*.test.ts

 RUN  v4.1.1 /Users/hanfox/Desktop/code/self/agent/agentx/iamwho/opencli

 Test Files  6 passed (6)
      Tests  11 passed (11)

[Astro-Han]

Left one P2 note on --thread validation. The issue is not isolated to one command, it comes from a shared helper path used by ask, send, and read: malformed or partial thread values can fall through, be treated as a match for the current URL, and end up operating on the wrong conversation instead of failing early.

Other than that, this looks solid to me. The scope is tight, the command wiring is consistent across ask, send, and read, and the added tests cover the main happy path well.

I'm reviewing this as a contributor, not a maintainer, but from that angle I think the PR is in good shape once that shared edge case is addressed.

[Astro-Han]

If --thread is malformed or only a partial id, parseDoubaoConversationId() falls back to the raw input. That becomes risky here because navigateToConversation() treats currentUrl.includes(/chat/${conversationId}) as an exact match, so a value like 123 will match an existing /chat/1234567890123 URL and skip navigation. In that case ask can post into the wrong conversation instead of failing fast. I think this should validate the parsed id before navigation, or tighten the current URL check to compare the full path segment.