Strictness checkbox in collection date range filter jumps on page load

[corneliusroemer]

The strictness checkbox in collection date range filter jumps on page load which isn't very professional and no other element on the page jumps like this so we should probably get rid of the animation.

[theosanderson]

The strictness checkbox actually seems stuck enabled!

[theosanderson]

@theosanderson-agent please investigate

[corneliusroemer]

I also noticed, to preempt your agent: It's stuck when you don't have a date in it because we store state implicitly through the url parameters. We deduce from whether upper/lower is used. When you don't have a date set at all it just defaults to strict. We've had that for a long time.

[theosanderson]

ah, thanks - yeah not ideal - maybe the agent will suggest sthng

[corneliusroemer]

Could just add a url param that encodes default in case of no date being used

[theosanderson-agent]

Investigated and opened a draft PR: #6485.

Root cause: DateRangeField had a feedback loop between its two effects. Toggling the checkbox flipped local strictMode to false, the write-out effect then cleared the four backing bound fields from URL state (since no dates had been entered), and the read-in effect re-derived strictMode from the now-empty fieldValues. isStrictMode(false, false, false, false) falls through to its default return true, snapping the checkbox back to checked. The brief flip is the visible 'jump'; the snap-back is the 'stuck enabled' behaviour.

Fix: In the read-in effect, only re-derive strictMode when at least one of the four bound fields is actually defined in fieldValues — otherwise there's no signal and we preserve the user's selection. External (URL-driven) updates still propagate normally because they always carry at least one defined bound.

Added a regression test that toggles the checkbox with no dates entered and asserts it stays unchecked. The test fails on main and passes with the fix; all 214 existing SearchPage tests still pass.