[extolkom]

Description

Closes #853

Problem

In AssetFilter.tsx, managing focusedIndex resets via effects with suppression comments introduced stale-closure risks and subtle desynchronization when the filtered asset list changed. While previous cleanup commits removed the effect, the search input's onChange handler omitted setFocusedIndex(0), leaving keyboard focus on an arbitrary index after typing rather than resetting to the top search result.

What Changed and Why it Removes Stale-Closure Risk

1. Direct Event Handler Reset: Resetting focusedIndex to 0 inside the search input's onChange handler and the clear-search button click handlers updates state synchronously in response to user input. This avoids any asynchronous effect cycle, eliminating stale closures and race conditions.
2. Safe Clamping: Keyboard navigation and row rendering continue to use the clamped effectiveFocusedIndex (Math.max(-1, Math.min(focusedIndex, filtered.length - 1))), ensuring the focused index never points out of bounds even if a list dynamically shrinks.
3. No ESLint Comments: Zero eslint-disable react-hooks comments remain in AssetFilter.tsx.

Acceptance Criteria Mapping

Acceptance Criterion	Implementation / Test
No eslint-disable react-hooks comments in AssetFilter.tsx	Clean file verification with npx eslint src/components/AssetFilter.tsx (0 errors, 0 warnings).
Typing in the filter resets keyboard focus to index 0	Added setFocusedIndex(0) to the filter input's onChange handler in AssetFilter.tsx.
AssetFilter.test.tsx covers: focus resets on filter change	Added test "resets keyboard focus to index 0 on filter change (#853)" (moves focus down to index 2, types, and asserts index 0 is focused).
AssetFilter.test.tsx covers: arrow-key nav works after typing	Added test "allows arrow-key navigation after typing in filter (#853)" (types, navigates with ArrowDown/ArrowUp, and verifies focused row and selection).

How to Verify

1. Run tests:

   npm test -- src/components/AssetFilter.test.tsx