fix(a11y): keep keyboard-focused search suggestion visible (WCAG 2.4.11)

[WanjohiSammy]

Problem

WCAG 2.4.11 Focus Not Obscured (Minimum). When a user types in the top-navbar search box and arrows through the autocomplete suggestions, the keyboard-focused suggestion could be scrolled off-screen (obscured), because the page does not reliably keep it in view. This is most visible on short or zoomed-in viewports where the suggestion list is taller than the visible area.

This completes the earlier partial fix in #406 (scroll active search suggestion into view), which did not fully resolve the issue across browsers and arrow directions.

Root cause

The navbar search input is driven by two keyboard navigators at once:

1. Legacy Swiftype (jquery.swiftype.autocomplete.js) - owned the visible highlight (active class) and Enter selection.
2. ARIA ComboboxAutocomplete (combobox-autocomplete.js) - owns aria-selected / aria-activedescendant and scroll-into-view.

Fix

Make the suggestion list scroll internally (the standard ARIA combobox pattern) and make the combobox the single keyboard navigator.

Before

After

[gathogojr]

This PR directly modifies public/jquery.swiftype.autocomplete.js, which appears to be a vendored third-party library (the jQuery Swiftype autocomplete plugin) rather than code we own. Patching a vendored dependency in place makes it hard to pull upstream updates/security fixes later, since our changes will conflict or get silently overwritten/lost.

Could we instead:

• Check if Swiftype/jQuery already exposes hooks/events for this behavior (e.g., a config option or extension point) instead of editing the library source, or
• If a patch is truly required, isolate it (e.g., a small wrapper/monkey-patch applied after load, or a documented local fork with a clear header noting what was changed and why), so future upstream updates can be reconciled more easily.

Could you clarify whether this file is actually maintained upstream/via a package manager, or if it's already treated as a local, hand-maintained copy in this repo? That would determine whether this is a real risk or a non-issue.