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/useEmaIdpLoginState.ts

@@ -35,6 +35,16 @@ export function useEmaIdpLoginState(
 
   useEffect(() => {
     if (!active) return;
+    // Reading the persisted IdP session *is* the external system this effect
+    // exists to synchronize with, and the read is asynchronous: the
+    // `loginState` commit happens in a continuation after
+    // `getEmaIdpLoginState` resolves. `set-state-in-effect` follows the call
+    // into `refresh` without modelling the `await`, so it reports every
+    // "fetch on open" effect alike — verified against a minimal hook whose
+    // only setState is after an `await`. The one commit here that *is*
+    // synchronous is the no-issuer reset to "none", which settles in a single
+    // extra render rather than cascading.
+    // eslint-disable-next-line react-hooks/set-state-in-effect -- async read of an external store
     void refresh();
   }, [active, refresh]);