feat(website, config): add an option for search presets

[anna-parker]

resolves #5904

Screenshot

PR Checklist

• All necessary documentation has been adapted.
• The implemented feature is covered by appropriate, automated tests.
• Any manual testing that has been done is documented (i.e. what exactly was tested?)

🚀 Preview: Add preview label to enable

[claude]

Claude finished @anna-parker's task in 4m 17s —— View job

---

Code Review

• Gather context and read changed files
• Review website components
• Review Kubernetes/config changes
• Review tests
• Post final review

---

The implementation looks solid overall — the preset logic is well thought out, particularly the multi-select consensus check (only apply a preset if all selected options agree on the value). Good test coverage for the multi-select case. A few issues worth addressing:

Issues

Duplicate type definition
FieldPresetMap is defined identically in both MultiChoiceAutoCompleteField.tsx:26 and SingleChoiceAutoCompleteField.tsx:41. Since the Zod schema already has z.record(z.record(z.string())) in config.ts, the type should be derived there once and imported. Left an inline comment.

Missing tests for SingleChoiceAutoCompleteField presets
SingleChoiceAutoCompleteField received the same preset logic as MultiChoiceAutoCompleteField, but SingleChoiceAutoCompleteField.spec.tsx has no coverage for it. The MultiChoiceAutoCompleteField.spec.tsx fieldPresets block is a good template. Left an inline comment.

Stale preset state after page refresh
lastPresetKeysRef is in-memory only. If a user applies a preset, then refreshes the page, the preset field values remain in the URL but the ref is empty. Subsequent changes to the triggering field won't clear those stale values. This is a UX edge case rather than a bug, but it's worth documenting or noting as a known limitation. Left an inline comment.

Minor observations

• In _common-metadata.tpl, the fieldPresets block is repeated in both the per-segment and non-per-segment branches. It could be moved into loculus.standardWebsiteMetadata to reduce duplication, though this is cosmetic.
• The fieldPresets field added to config.ts:88 has no doc comment explaining the semantics (map from selected value → fields to auto-populate). Worth a short comment given the non-obvious behavior.

[claude]

The lastPresetKeysRef tracking is in-memory only. If a user refreshes the page, the URL still contains the preset-applied field values, but lastPresetKeysRef.current will be empty. Changing or clearing the triggering field after a refresh won't clean up those preset values.

This is a known limitation of using a ref for this kind of ephemeral state, but worth noting as a known edge case since the behaviour can seem surprising (stale filter values persist until manually cleared after a page reload).

[anna-parker]

I'm not sure if there is a better way to handle this, @theosanderson do you have any better ideas?