ref(lint): enable oxlint react/hooks

[ryan953]

Turns on oxlint's react/hooks rule, which was parked at 'off' behind a
TODO in oxlint.config.ts. The rule is part of the React Compiler set and
catches three things: a hook referenced as a value instead of being called, a
hook whose identity can change between renders, and a hook called
conditionally.

The tree had 48 violations across 28 files. One is a real bug, the rest are
deliberate indirection.

The bug. In the issue stream, the Affected Users tooltip tested the
imported usePageFilters hook rather than the useFilteredStats prop that its
sibling groupCount block uses. A function reference is always truthy, so
disabled was permanently false and the tooltip showed even when the stream
was not displaying filtered stats.

-      disabled={!usePageFilters}
+      disabled={!useFilteredStats}

Everything else is a place where a hook is reached through a value, so
React Compiler cannot prove the binding is stable. Three patterns cover all of
them, and each suppression carries the reason it is safe:

• The override registry (getOverride('react-hook:…')), which lets getsentry
  swap a hook implementation into the open-source frontend. Overrides register
  once before React renders, so the binding is fixed for the life of the app.
• useProgressiveQuery, which receives the query hook as an argument so it can
  run it at more than one accuracy tier.
• A dataset config or a call-site flag choosing between query hooks, where the
  selector is constant for the lifetime of the component.

None of these can be fixed without redesigning the mechanism itself, which is
well outside a lint sweep. The alternative — leaving the rule off — keeps the
real bug above invisible and lets the pattern spread, so suppressing with a
written reason seemed the better trade.

Reviewers may notice two directive spellings. Most sites use the repo's usual
// oxlint-disable-next-line, but where the diagnostic anchors to a line in
the middle of a wrapped expression, a preceding line cannot cover it, so those
use the trailing // oxlint-disable-line form instead. Inserting extra lines
there would also risk detaching a neighbouring directive from its target.

Also renames a useParamsValue test local to paramsValue; the use prefix
made the rule read it as a hook.

No feature flag — the behavior change is the one tooltip fix, gated on nothing.

[ryan953]

variable rename to make the compiler happy

[ryan953]

So, this was looking at the function called usePageFilters. Which is always defined, so this is never disabled.

[sentry]

Bug: The Tooltip for groupUsersCount is missing the disabled={!useFilteredStats} prop, so it is always enabled. The original bug this PR intended to fix remains.
_{Severity: LOW}

Suggested Fix

Add the disabled={!useFilteredStats} prop to the Tooltip component wrapping groupUsersCount, similar to how it is used for the groupCount tooltip. This will ensure the tooltip is only enabled when filtered stats are being shown.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: static/app/components/stream/group.tsx#L644

Potential issue: The pull request attempted to fix an issue where the "Affected Users"
tooltip was always enabled. The change removed the incorrect
`disabled={!usePageFilters}` prop from the `Tooltip` component for `groupUsersCount` but
failed to add the intended replacement, `disabled={!useFilteredStats}`. Because the
`Tooltip` component defaults to being enabled when the `disabled` prop is not provided,
the tooltip remains always visible on hover, even when filtered stats are not being
displayed. This means the original bug was not fixed.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[ryan953]

that's not the original bug this PR is aiming at