Journal Link to task: select the prefilled title on focus so typing replaces it

阅读 TaskTypeahead.tsx、其测试，以及第 250 行附近的 docs/FRONTEND.md。检查 handleFocus 和 handleClick 如何设置输入值并打开建议列表，然后为列出的焦点、点击、输入、光标位置和重新选择场景补充测试。满足验收标准且文档描述了选择行为后，即告完成；issue 还要求在 iOS Safari 和 Android Chrome 上进行手动检查。

Groomed 2026-11-08 — ready for implementation.

Original Description

Problem

In the journal "Link to task" picker (TaskTypeahead), focusing the input on a row that already has a linked task fills the input with the linked task's title (handleFocus calls setInputValue(selectedTitle)) but does not select that text. Typing then appends to the title instead of replacing it, so the filter text is the old title plus the new characters and matches nothing.

This is most visible since #423 added search by task ID: on a linked row, typing 42 gives Old title42, and the task #42 is not found. The behavior itself predates #423. The #478 review and the PR description both flagged it as a follow-up.

Expected

Focusing (or clicking) the input on a linked row selects the prefilled title, so the first keystroke replaces it. The user can still click again to place the caret and edit the title text.

Notes

• Web only: TaskTypeahead.tsx (handleFocus, handleClick) and its tests.
• Check keyboard focus (Tab into the input) and click or tap, including mobile, where selecting on focus can raise the selection handles.
• Related: #423 (search by ID, done, PR #478). No overlap with #464 (task title focus on the details page) or #479 (focus the edited row on return to the Tasks page).

User Story

Scope note: the only consumer of TaskTypeahead is DailyLogSection.tsx (the per-row pickers and the draft picker). TodosSection does not use it, so the original description's references to todo rows mean daily log rows.

As a journal user, I want the existing linked task title to be selected when I focus or click the "Link to task" input on a linked daily log row, so that my first keystroke replaces the title and I can find another task (for example by typing its ID) without deleting the old text first.

Implementation note: whether the select happens in handleFocus, handleClick or both is left to the builder. The behavior is fixed by the acceptance criteria below.

Acceptance Criteria

1. Given a daily log row linked to a task, when I focus the input with the keyboard (Tab), then the whole prefilled title is selected (selectionStart = 0, selectionEnd = title length) and the suggestion list opens.
2. Given a linked row whose input is not focused, when I click the input, then the whole title is selected once the click completes. The mouse caret placement must not overwrite the selection.
3. Given the title is selected, when I type 42, then the input value is 42 and the list is filtered by 42, so task #42 appears.
4. Given the input is focused and the list is open on a linked row, when I click the input again, then the caret is placed at the click position and the title is not re-selected, so I can edit the title text.
5. Given I just chose a task (the input keeps focus and the list is closed), when I click the input, then the list reopens and the new title is selected.
6. Given the title is selected, when I press Backspace, then the filter text is empty and the first 10 tasks are shown. The row stays linked until I choose "None" or another task.
7. Given a row with no linked task, when I focus or click the input, then behavior is unchanged: the input is empty, the list opens and nothing is selected.
8. Given the input is focused, when I press Escape, then the existing behavior still applies (the list closes, then onEscape is called or the input blurs). Blur still closes the list after 150ms.
9. Given the change is implemented, when the test suite runs, then all existing tests pass. New tests cover Tab focus, click focus, typing-replaces, re-click-places-caret and re-select after a selection. The tests assert selectionStart and selectionEnd.
10. Given the PR is opened, when it is reviewed, then the PR description records a manual check of selection behavior on iOS Safari and Android Chrome, including whether the selection handles are disruptive.
11. Given the change ships, when I read docs/FRONTEND.md (around line 250), then it states that focusing or clicking a linked row selects the title.

Edge Cases

• Mouse timing: the browser places the caret on mousedown, after focus. A select() inside handleFocus may be overwritten, so the select may need to be deferred or done on click.
• Click guard: handleClick returns early when the list is already open. The click that reopens the list after a selection must still select (AC 5), while a click on an open list must not (AC 4).
• Mobile fallback: select-all applies on all devices, including touch. If the manual checks (AC 10) show the selection handles are disruptive, skip the select on coarse pointers via isCoarsePointer() in lib/pointer.ts, and document that in docs/FRONTEND.md. iOS Safari behavior is currently unverified, and the mobile tests mock the picker.
• Tab focus: browsers often select all on Tab already. Verify this so the code does not conflict with it.
• Title changes while focused: a refetch or rename of the linked task while the input is focused could leave the selection stale.
• Accidental unlink: select-all, then Backspace, then blur does not unlink. This is existing behavior, and "None" remains the only unlink path.

Out of Scope

• Unlinking a task by clearing the text.
• Changes to search, filter or ID-search logic (#423).
• Changes to TodosSection, other text inputs or NotesSection, including their caret-to-end-on-focus code.
• Changes to keyboard navigation, the 150ms blur timer or programmatic focus.
• Any API, assistant or generated-client change.
• Overlap with #464 and #479.