Wheel-contents check only asserts index.html; the assets it references are unguarded

## Summary

The packaging regression check for #610 asserts that the built wheel contains `cli_agent_orchestrator/web_ui/index.html`. It does not assert the asset files that `index.html` loads, so the check cannot distinguish "the web UI shipped" from "only its entry point shipped".

## Confirmed by execution, not inspection

With the `[tool.hatch.build] artifacts` glob narrowed from `src/cli_agent_orchestrator/web_ui/**` to `src/cli_agent_orchestrator/web_ui/index.html`:

- the check passed 4 out of 4 runs (exit 0, `1 passed`)
- the resulting wheel contained exactly one web UI member, `cli_agent_orchestrator/web_ui/index.html`, with `assets/*` absent

## Why that wheel is still broken

`index.html` hard-references its bundles:

```html

```

So that wheel serves `GET /` as HTTP 200 with a body of only `

` while its JS and CSS 404 -- the operator-visible symptom described in #610, reached with the check green.

## Coverage

The built web UI is 5 files: `index.html`, `favicon.svg`, `favicon.ico`, one hashed CSS bundle, and one hashed JS bundle. The check currently covers 1 of them. A narrowed or typo'd glob is precisely the failure the check's own docstring says it exists to catch.

## Suggested fix

Assert the built `web_ui` file set against the wheel's members rather than a single hardcoded path. A negative control for that change would be to drop one asset while keeping `index.html` -- the check should fail.

Happy to supply the exact glob edit and the wheel member listing from those runs if that would be useful.

Locate the packaging regression check described in the issue and inspect how the built wheel's members are asserted. Run the existing check, then verify it covers all five web UI files: index.html, both favicon files, and the hashed CSS and JS bundles. Done means removing any one asset makes the check fail.

Written by the indexing model from the issue text.