fix(website): stop date range strictness checkbox stuck on strict when no date entered

[theosanderson-agent]

Fixes #6483

What was happening

When you toggled the strictness checkbox in a DateRangeField (e.g. the Collection date filter) without having entered any dates, was stuck on. This matches the user reports in #6483:

• The checkbox "actually seems stuck enabled"

Fix

In the read-in effect, skip the setStrictMode call when none of the four bound fields are defined — there is no signal to derive from in that case, so we preserve the user's manual selection. When at least one field is defined the existing isStrictMode logic still runs and stays in charge.

The write-out effect is unchanged. External (URL-driven) changes still flow in correctly because they always come with at least one bound defined.

🤖 Generated with Claude Code

🚀 Preview: https://fix-date-range-strictness.loculus.org

[corneliusroemer]

@theosanderson-agent Not sure it fixes the checkbox jump - it's a different issue you're solving here, of it being stuck

[claude]

Claude finished @theosanderson's task in 2m 15s —— View job

---

Code Review

• Gather context and read changed files
• Review DateRangeField.tsx changes
• Review DateRangeField.spec.tsx tests
• Post final review

---

The fix correctly breaks the feedback loop that caused the checkbox to snap back. Here's the bug cycle that was happening before:

1. User toggles strictMode to false (no dates entered)
2. The write-out effect fires and sets all four fields to null/'' in parent state
3. The parent deletes those keys from fieldValues
4. The read-in effect fires (because fieldValues changed) and calls isStrictMode(false, false, false, false) → returns true (default fallback)
5. setStrictMode(true) overrides the user's toggle → checkbox snaps back

The guard at line 71 (if (lowerFromDefined || ...) breaks this cycle cleanly.

One pre-existing issue to be aware of (not introduced by this PR): setLowerValue/setUpperValue at lines 74-75 use lowerField.name/upperField.name, which are stale closures from the previous render (based on the old strictMode). If setStrictMode changes mode in the same effect, the values on those lines are read from the old field names. This self-corrects on the next render, so it's not a visible bug, but it's worth knowing about.

Tests look solid. The new integration test at line 161 properly mirrors production state management (null/'' deletes keys), which is exactly the condition required to reproduce the bug. Good that it's not just a unit test of the guard condition itself but exercises the full cycle.

One thing I'd flag: the corneliusroemer comment says "it's a different issue you're solving here, of it being stuck". The PR description says it fixes the "stuck enabled" behavior from #6483 — that is exactly what this fixes. If there's also a "jump" issue (a brief visual flicker even when dates are entered), that would be a separate problem. Worth confirming with the reporter whether the "stuck" case was the main complaint or if there's also a jump scenario that needs addressing.

LGTM otherwise — the fix is correct, targeted, and well-tested.

[corneliusroemer]

Looks reasonable to set strict mode via URL params only when defined. I also tested and seems to work.