Publish active chatId to NativeInputState (per-tab)

[YoussefKeyrouz]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1212810093780571/task/1215004327619963?focus=true

Description

Tech Design: https://app.asana.com/1/137249556945/project/1212810093780571/task/1214935104654912?focus=true (Do not merge until approved)

Per-chat reasoning persistence groundwork (2 of 3).

#8659 added the reasoningMode field on DuckAiChat and a getChatById lookup on the store. This PR adds the runtime signal: per-tab NativeInputState now carries the chat id of the active Duck.ai chat (if any), produced from the active tab's URL. Nothing consumes the field yet. The data-layer publish is verified in isolation. The next PR (3/3) will wire the consumers (reasoning picker derives modes from the chat's model).

What changed:

• NativeInputState adds a chatId: String? (default null) in duckchat-api.
• NativeInputModeWidget interface adds bindChatIdSource
• NativeInputModeWidgetViewModel publishes the chat id into per-tab state.
• extractDuckAiChatId(rawUrl) in NativeInputManager

Out of scope (deferred to PR 3/3):

• Reasoning picker reading the chat id to derive available modes from the chat's stored model.
• Submission code reading chat id to send the chat's stored model and effort.

Steps to test this PR

• Filter logcat by "Duck.ai native input: active chatId":
  • Open Duck.ai with no existing chat → expect a log line with chatId=null.
  • Tap an existing chat from history → expect a log line with the chat's id.
  • Switch to another chat in the same tab→ expect chatId= changes to the new chat.

---

Note

Medium Risk
Moderate risk because it changes per-tab native input state publication and adds a new chatId field that downstream consumers may start relying on; includes a temporary log that could be noisy if left in production.

Overview
Publishes the active Duck.ai chatId into per-tab NativeInputState so native-input consumers can resolve per-chat state.

RealNativeInputManager now extracts chatID from the current tab URL (via new extractDuckAiChatId) and binds it into the widget; the widget forwards this flow to the NativeInputModeWidgetViewModel, which buffers and writes chatId to the per-tab state store (handling the attach/configure race).

Adds unit coverage for extractDuckAiChatId parsing and for setActiveChatId state publishing/clearing behavior.

^{Reviewed by Cursor Bugbot for commit b943724. Bugbot is set up for automated code reviews on this repo. Configure here.}

[YoussefKeyrouz]

• Per-chat reasoning effort in contextual sheet #8674
• Per-chat model and reasoning restoration on existing Duck.ai chats. #8666
• Publish active chatId to NativeInputState (per-tab) #8664 👈 (View in Graphite)
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[malmstein]

smoke-tested the APK and the chatId log lines fire as expected for each transition (null → existing chat → switching chats). nice that the test suite includes the buffered-before-configure regression — useful defensive coverage. the main concern is the stale-chatId race across tab switches: the existing setSelectedTool pattern in the same file already solves this for an equivalent per-tab String field, and switching to it removes a real edge from PR 3/3 before it lands. otherwise the refactor of isExistingDuckAiChat → extractDuckAiChatId is clean and the new test coverage is thorough.

(separate note for context: this PR adds a field to NativeInputState in duckchat-api. my own ongoing refactor (#8556 / #8570 / planned PR 3b) is co-evolving the same data class. no conflict in this PR's diff, but worth syncing on the field ownership pattern as more contributors add per-tab properties.)