refactor(dhcp): centralize reservation device-option data source

[PeterJhongLinksys]

Summary

Refactors the DHCP reservation cards so the client-device data lookup lives in
the notifier (data layer) rather than the views, and wires device autocomplete
options into the local-network add dialog. Also completes localization for two
duplicate-address validation strings and includes a small hooks fix.

Changes

• Data/UI split: extract the cross-provider client-device read out of the
  reservation cards into UspDhcpReservationsNotifier.deviceOptions(), which
  returns pure data (ReservationDeviceOption records) instead of UI Kit types.
  The cards now map that data to AppAutoCompleteOption at the call site — the
  cross-provider read stays in the notifier, the UI projection stays in the view.
• Local-network dialog: pass device autocomplete options into the add
  reservation dialog (previously created without them).
• l10n: add duplicateMacAddress / duplicateIpAddress across all 26
  locales (previously only en).
• Hooks: use $CLAUDE_PROJECT_DIR absolute paths in the PreToolUse Bash
  hooks so they work regardless of the shell's working directory.

Testing

• Added unit tests for deviceOptions(): mapping, name fallback
  (friendlyName → hostName → mac), mesh-node (master/slave) exclusion, empty case.
• flutter analyze clean on changed files.
• Affected functional tests pass (28 tests: notifier + dhcp_data_provider).
• flutter gen-l10n succeeds; generated getters verified.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[AustinChangLinksys]

🤖 Automated Review — Round 1 · 9028ec6..6acf4e5 (full)

Verdict: ✅ APPROVE — Refactor direction is correct; 0 Critical. Six warnings flagged for author follow-up.

	Conf.	Where	Issue (one-liner)
⚠️	High	usp_dhcp_reservations_notifier.dart:185	[both reviewers] valueOrNull silently returns [] during AsyncLoading — autocomplete shows blank with no UX feedback
⚠️	High	detail_card.dart:106 + card.dart:150	_buildDeviceOptions projection logic fully duplicated in two card widgets (DRY violation)
⚠️	High	(no card test files)	_buildDeviceOptions filter/mapping logic in cards has no widget or unit test coverage
⚠️	Med	usp_dhcp_reservations_notifier.dart:13	DHCP AutoDispose L2 directly reads Devices L1 (devicesDataProvider) — cross-domain coupling
⚠️	Med	usp_dhcp_reservations_notifier.dart:183	deviceOptions() mixes UI-hint concern into reservation-CRUD Notifier — single-responsibility tension
⚠️	Med	lib/l10n/app_*.arb	duplicateMacAddress/duplicateIpAddress were referenced in base but translations only arrive in this PR — base had broken l10n state
💡	High	.claude/settings.json	`cd ...
💡	Med	usp_dhcp_reservations_notifier.dart:183	deviceOptions() name too generic; consider clientDeviceSuggestions()

Confidence: High = code-verified · Med = located + reasoned, not fully confirmed · Low = speculative, please double-check.
Items marked [both reviewers] were independently flagged by two agents → higher confidence.

⚠️ Warning Details

W1 — valueOrNull silent empty list during AsyncLoading High · [both reviewers]

• usp_dhcp_reservations_notifier.dart:185

final devices =
    ref.read(devicesDataProvider).valueOrNull?.clientDevices ?? [];

devicesDataProvider is an AsyncNotifier; while it is in AsyncLoading (startup, SSE-triggered refetch), valueOrNull returns null and deviceOptions() silently returns []. The user opening the Add Reservation dialog will see blank MAC/IP autocomplete fields with no loading indicator.

Fix: In the card's _showAddDhcpDialog, check ref.read(devicesDataProvider).hasValue before opening the dialog and show a loading state if not; OR make deviceOptions() an async method that awaits devicesDataProvider.future.

---

W2 — _buildDeviceOptions duplicated in two cards High

• lib/page/dhcp/views/components/usp_dhcp_reservations_detail_card.dart:106–127
• lib/page/local_network/cards/usp_dhcp_reservations_card.dart:150–175

Both methods contain identical logic: call deviceOptions(), filter by mac.isNotEmpty / ip.isNotEmpty, map to AppAutoCompleteOption, return a ({mac, ip}) record. The PR centralised the data source but left the projection duplicated.

Fix: Extract a top-level function or extension (e.g., in lib/page/dhcp/views/) shared by both cards.

---

W3 — No tests for card-layer _buildDeviceOptions High

No widget or unit tests exist for the filter (mac.isNotEmpty, ip.isNotEmpty) or AppAutoCompleteOption mapping logic in either card. Constitution Article I §1.1 requires test coverage for all business logic.

Fix: Add widget tests (or unit tests extracting the helper) verifying: empty MAC excluded, empty IP excluded, correct label/value/subtitle mapping.

---

W4 — Cross-domain coupling: DHCP L2 reads Devices L1 Med

• lib/page/dhcp/providers/usp_dhcp_reservations_notifier.dart:13

import 'package:privacy_gui/page/devices/providers/devices_data_provider.dart';

UspDhcpReservationsNotifier is an AutoDisposeNotifier in the DHCP domain. It now directly imports and ref.reads devicesDataProvider (Devices domain L1). While Article IV Rule 2 allows L2 to ref.read L1, the intent is intra-domain coordination. Cross-domain horizontal reads accumulate coupling over time.

Fix (preferred): Introduce a reservationDeviceOptionsProvider in a shared layer that reads devicesDataProvider and is consumed directly by the two cards — removing the cross-domain dependency from the Notifier entirely.

---

W5 — Single-responsibility tension in Notifier Med

• lib/page/dhcp/providers/usp_dhcp_reservations_notifier.dart:183–196

UspDhcpReservationsNotifier core responsibility is DHCP reservation CRUD state. deviceOptions() provides UI autocomplete hints — a UI concern mixed into a state-management class. Views call ref.read(uspDhcpReservationsProvider.notifier).deviceOptions() directly, bypassing normal Provider state consumption.

Fix: Same as W4. If kept in the Notifier, add a doc comment marking it as a View-helper exception.

---

W6 — l10n translations missing from base branch Med

• lib/l10n/app_*.arb (26 locale files)

dhcp_reservation_edit_dialog.dart at base SHA 9028ec6e (lines 120, 125, 137, 138) already references loc(context).duplicateMacAddress and loc(context).duplicateIpAddress. The ARB translations arrive only in this PR, meaning the base branch had broken l10n (missing generated getters) until now.

Fix: Ensure future PRs that add loc(context).xxx references include all ARB file updates atomically in the same commit.

✅ What looks good

• Refactor direction: Moving device data reads out of View widgets into the Notifier is the right layering step; Views now consume a clean ReservationDeviceOption typedef instead of raw ClientDevice.
• ReservationDeviceOption typedef: Clean named-record design with only the fields the View needs — good data encapsulation.
• Test suite additions: Four new deviceOptions() tests are well-structured, covering happy path, fallback naming (hostName then mac), mesh-node exclusion (via clientDevices which already filters master/slave), and empty-device edge case.
• l10n completeness: All 26 locale files updated consistently, inserted in alphabetically correct positions.
• .claude/settings.json hook fixes: Using $CLAUDE_PROJECT_DIR for absolute paths is correct and portable.
• No security or correctness issues found in the production diff.

Cross-reviewed by two independent agents (security+correctness / architecture+maintainability). Automated — please sanity-check before merge.