chore: lint core/react with eslint-plugin-react-hooks (#2192)

`eslint-plugin-react-hooks` was a `clients/web` devDependency only, and each
client's `eslint .` is scoped to its own directory — so the whole hook rule
set had never looked at `core/react/`, a directory of nothing but React
hooks. "Neither surface has JSX" was the stated reason and was never a good
one: the rules judge hooks, not JSX.

Add the plugin at the root and apply it in a `core/react/**` block (scoped
there rather than to all of `core/**`, since the rules key off the `use`
prefix), with `exhaustive-deps` promoted to `error` as `clients/web` does.

Resolve the 15 findings it then reports:

- `useSettingsDraft` / `useClientSettingsDraft` seed their draft during
  render instead of in a `targetId`/`opened`-keyed effect, so the previous
  target's values never reach the DOM — the same rule `clients/web` spells
  `useValueChange`. Their "latest value" refs move from render-time writes
  into an effect; every reader (the debounce timer, `flush`, `onChange`)
  runs after a commit, so a post-commit write is what they need.
- The three async loaders keep their effects behind justified inline
  disables: `set-state-in-effect` follows a call into an async function
  without modelling the `await`, verified against a minimal hook whose only
  setState is in a continuation.
- `useInitialConfig`'s cleanup bump keeps reading `generation.current` at
  teardown — the rule's "copy it into a variable" advice would restore a
  stale request token and let a superseded response commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013hzwzS8UvBsr4yZm7o7sev
Signed-off-by: cliffhall <cliff@futurescale.com>

core/react/useInitialConfig.ts

@@ -245,11 +245,25 @@ export function useInitialConfig(
   }, [base, authToken, doFetch]);
 
   useEffect(() => {
+    // `load` commits nothing before its first `await`: it claims a generation
+    // token, builds headers, and only then fetches, so every setState it makes
+    // runs in a continuation. `set-state-in-effect` follows the call into an
+    // async function without modelling the `await` boundary, so it reports
+    // this even though there is no synchronous commit to cascade from.
+    // eslint-disable-next-line react-hooks/set-state-in-effect -- no commit before the first await
     void load();
     return () => {
       // Invalidate whatever is in flight: this fires on unmount and on a
       // `baseUrl`/`authToken` change, and in both cases a response for the
       // old inputs must not commit.
+      //
+      // `generation` is a monotonic request token, not a ref to a rendered
+      // node. `exhaustive-deps`' advice — copy `generation.current` into a
+      // variable inside the effect and use the copy here — is exactly wrong:
+      // the cleanup must bump whatever the counter holds *at teardown*, since
+      // that is what invalidates the load currently in flight. A value
+      // captured at effect setup would let a superseded response commit.
+      // eslint-disable-next-line react-hooks/exhaustive-deps -- must read the token at teardown
       generation.current++;
     };
   }, [load]);