fix(frontend-v2): pin eslint to v9 for plugin compatibility

[jakehobbs]

ESLint was bumped to 10.4.0 by dependabot (commit 0ff3e83), but ESLint 10 removed context.getFilename(), which eslint-plugin-react@7.37.5 (pulled in transitively by eslint-config-next@16.2.6) still calls — crashing every lint run with contextOrFilename.getFilename is not a function. This is a known upstream issue with no fixed eslint-plugin-react/eslint-config-next release yet, and the maintainer-tracked recommendation is to stay on ESLint v9 (which eslint-config-next@16.2.6 fully supports). This PR pins eslint back to ^9.39.4 so linting works again; we can re-bump to v10 once upstream ships compatibility.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@jakehobbs, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 53 minutes and 31 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 94846c68-763b-4ff8-9b0b-a3546f086e51

📥 Commits

Reviewing files that changed from the base of the PR and between c78e8e9 and feb02e5.

⛔ Files ignored due to path filters (1)

• frontend-v2/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (3)

• frontend-v2/package.json
• frontend-v2/src/app/(authed)/activists/filters/date-range-filter.tsx
• frontend-v2/src/app/(authed)/events/useActivistRegistry.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jakehobbs/port-louis

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This PR downgrades/pins the frontend-v2 ESLint dependency to the supported v9 range so the Next.js ESLint config and transitive React plugin can run without the ESLint 10 API incompatibility.

Changes:

• Updates eslint from ^10.4.0 to ^9.39.4.
• Refreshes the frontend-v2 lockfile so ESLint-related dependencies resolve against ESLint 9.39.4.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
frontend-v2/package.json	Changes the frontend-v2 devDependency range for ESLint to v9.
frontend-v2/pnpm-lock.yaml	Updates resolved ESLint and related peer dependency snapshots to ESLint 9.39.4.

Files not reviewed (1)

• frontend-v2/pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jakehobbs]

Review summary

I reviewed the workspace diff: an eslint downgrade (^10.4.0 → ^9.39.4, plus lockfile) and two source files updated to satisfy react-hooks rules that the version change surfaced.

date-range-filter.tsx — Replaces a useEffect-based prop→state sync with React's documented "adjust state during render" pattern (prevUnit guard + setLocalUnit). Behavior is equivalent to the old effect (resets localUnit only when the unit prop actually changes; user-driven changes via handleUnitChange are preserved), and it avoids the extra render/flash. Correct.

useActivistRegistry.ts — Replaces useRef(new ActivistRegistry()) with a useState(() => new ActivistRegistry()) lazy initializer. The instance is still stable for the component's lifetime, it's now legitimately readable during render, and the lazy initializer avoids allocating a throwaway ActivistRegistry on every render that the old useRef argument incurred. The added registry entries in the effect dependency arrays are no-ops since the value is stable. The two react-hooks/set-state-in-effect disables are correctly scoped to genuine one-shot loading flags. Behavior-preserving.

No findings to flag. The changes are correct, behavior-preserving, and well-commented. The eslint pin to v9 is reasonable given eslint-plugin-react-hooks/eslint-config-next compatibility. I did not post any inline comments.