Job Dashboard search: native clear button doesn't reset filtered results

> *This was generated by AI during triage.*

Split from #2954 (concern 1 of 2 — the other concern, broader search-scope UX, remains on #2954 as `ready-for-human`).

## Background

The `[job_dashboard]` shortcode renders a search field that filters the logged-in employer's own listings. The search element is an `` inside a plain ``. On submit, the form puts `?search=` in the URL, the PHP shortcode reads `$_GET['search']`, and the listings are filtered via `WP_Query`'s `s` parameter.

Browsers that render the native clear button on `` — Chrome and Safari at the time of writing; Firefox doesn't — show a small "×" inside the input when the field has text. **Clicking that × clears the input's DOM value but doesn't submit the form**, so the URL still carries `?search=` and the dashboard stays filtered. The user has no obvious way to clear the filter short of manually deleting the URL parameter or retyping and submitting an empty search.

The plugin doesn't currently emit any JavaScript that ties the input's native clear gesture to a re-render of the dashboard.

## Agent Brief

**Category:** bug
**Summary:** Clicking the native "×" inside the Job Dashboard's search input clears the field visually but doesn't refresh the listing — the URL's `?search=` parameter is still active so the filter persists.

**Current behaviour:**

- User searches on the Job Dashboard. URL becomes `…/job-dashboard/?search=foo`. Listings are filtered.
- User clicks the browser-rendered "×" inside the search input. The input visually empties, but the form is not submitted; the URL retains `?search=foo`; the listings remain filtered.
- The user's only way to clear the filter is to manually edit/remove the query parameter or type something else and re-submit.

https://github.com/user-attachments/assets/f97485cd-3a14-488a-a2e6-45acc6f0af59

**Desired behaviour:**

- When the user clears the search field via the native clear control (which fires a `search` event in WebKit/Blink, and an `input` event reaching empty value in all browsers), the form should re-submit with no `search` term — restoring the unfiltered dashboard.
- When the user clears the search field by selecting all and pressing delete, the same outcome should apply (input event reaching empty value).
- Behaviour must not interfere with normal typing (i.e. submitting after every keystroke is not desired — only when the field transitions to empty *after* having been non-empty during this session).
- Firefox users (no native ×) are unaffected; for them the existing submit-the-form-with-empty-value behaviour already works.

**Key interfaces:**

- The Job Dashboard template renders the search input with `name=\"search\"` inside a GET form. The agent should locate that input (currently in `templates/job-dashboard.php`, but treat that as informative; use the rendered HTML structure as the contract — the input has `type=\"search\"` and `name=\"search\"` inside the dashboard's filter form).
- A small frontend script needs to be enqueued only on pages rendering the Job Dashboard shortcode. Look at how the dashboard already enqueues its own scripts (e.g. the dashboard overlay JavaScript registered when the shortcode runs) and follow the same pattern.
- No PHP behaviour change is required — `WP_Query`'s handling of an empty `s` parameter already returns the unfiltered set.

**Acceptance criteria:**

- [ ] On Chrome and Safari, with the search field non-empty and the dashboard filtered, clicking the input's native "×" causes the dashboard to reload with no `search` query parameter and the full listing visible.
- [ ] On Firefox (no native ×), behaviour is unchanged — submitting an empty search still works.
- [ ] Selecting all text in the search field and pressing delete (without clicking submit) also triggers the same clear-and-reload, in all three browsers.
- [ ] Typing characters into the search field does not trigger any premature submission; submission only happens on user-initiated clear or on form submit as today.
- [ ] No JavaScript console errors on pages that include the dashboard.
- [ ] The new script is only loaded on pages that render the `[job_dashboard]` shortcode — not on the public `[jobs]` listing or anywhere else.

**Out of scope:**

- The broader concern about WordPress core's `s` search being token-OR across the entire post body (tracked on #2954, remains `ready-for-human`).
- Adding a separate visible "Clear" button or "Reset" link to the dashboard UI — concern 1 here is specifically about making the existing native × control behave as users expect. A standalone control is a separate design decision.
- Any change to the public `[jobs]` listing's search UI (it has its own "Reset" link and is unrelated).
- Server-side validation/sanitisation of the `search` parameter (already handled).