v0.3.0 — rebrand: PXEForge → OpenPXE, Gated → Queued Deployment

Full rename to match the openpxe.com brand. The product now reads as a
polished open-source project rather than a personal-tool nickname:
the anvil/forge metaphor is gone, replaced with the rainbow-horizon
brand mark from the marketing site.

## Naming changes

**PXEForge → OpenPXE** everywhere it's user-visible or developer-
facing:
- All 8 crate package names (`pxeforge-*` → `openpxe-*`).
- The bin crate dir + binary (`crates/pxeforge` → `crates/openpxe`,
  `bin = "openpxe"`).
- Env vars: `PXEFORGE_*` → `OPENPXE_*` (no compat shim — pre-beta).
- Tracing targets: `pxeforge::*` → `openpxe::*`.
- Prometheus metrics: `pxeforge_*` → `openpxe_*` (pre-beta; nobody
  has dashboards on these yet).
- Container image: `gitea.milesward.dev/mward4/openpxe:0.3.0`.
- All in-tree paths: `/var/lib/openpxe/{isos,work,smb}`,
  `/usr/share/openpxe/ipxe`, `/etc/openpxe/...`.
- Unraid template renamed `pxeforge.xml` → `openpxe.xml`.
- README, NEXT_PHASE.md, architecture.md, comments, and the WebUI
  brand string.

**Gated Deployment → Queued Deployment** as the user-facing concept:
- `Settings::TimeoutAction::GatedDeployment` →
  `QueuedDeployment` (with `#[serde(alias = "gated_deployment")]`
  so v0.2.0 settings.json files keep deserializing).
- Rust types: `Gate` → `QueueEntry`, `GateQueue` → `DeploymentQueue`,
  `GateInner` → `QueueEntryInner`.
- File: `crates/core/src/gate.rs` → `crates/core/src/queue.rs`.
- HTTP routes: `/api/gate/*` → `/api/queue/*`. The JSON list key
  flipped from `"gates"` to `"entries"` to match.
- iPXE shortcut: `/boot/_gate.ipxe` → `/boot/_queue.ipxe`. The
  top-level menu's item id is now `queue` instead of `gate`.
- WebUI sidebar tab: "Forge Gate" → "Queue".
- Field on `AppState`: `gates` → `queue`.

## Brand assets

The anvil + forging-sparks logos are dropped:
- `logo.svg` is now a 24×24 medallion filled with the
  `rainbow-horizon` gradient from openpxe.com (sliding hue rotation
  via SMIL on the gradient stops, no JS needed).
- `anvil-forge.svg` renamed to `loader.svg` and rebuilt as a 64×64
  louder version of the same disc — used for page-load transitions
  and the imaging-progress widget. Adds a subtle scale pulse and a
  white inner-glow so it has dimensionality on either theme.

## CSS rename

- `.forge-progress` → `.queue-progress`
- `.forge-progress .anvil` → `.queue-progress .mark`
- `@keyframes forge-sheen` → `queue-sheen`
- `.loader .anvil` → `.loader .mark`
- "Heating the forge…" loader text → "Loading…"

The rest of the layout is untouched. Light/dark theme tokens and the
sidebar/topbar structure carry over from v0.2.0 unchanged — the
brief was "keeping the UI similar."

## Validation

- `cargo build --workspace` — clean.
- `cargo clippy --workspace --all-targets` — no warnings.
- `cargo test --workspace` — **66 tests passing**, same as v0.2.0.
- Local smoke run against the rebuilt release binary verifies:
  - `/boot.ipxe` emits `Queued Deployment` + `item queue` + chains
    `/boot/_queue.ipxe`
  - `/api/queue` returns `{count, entries}`
  - `/metrics` emits `openpxe_queue_count` (renamed)
  - `/assets/logo.svg` and `/assets/loader.svg` serve the new
    rainbow brand SVGs
  - `/api/status` reports version `0.3.0`

## Migration notes for operators on v0.2.0

- Container image path changed: pull
  `gitea.milesward.dev/mward4/openpxe:0.3.0` (not `pxeforge:`).
- Bind mounts: `/var/lib/openpxe/{isos,work,smb}` (not `pxeforge`).
  Move the host path or update the template.
- Env vars: replace `PXEFORGE_*` with `OPENPXE_*`. The Unraid
  template at `deploy/unraid/openpxe.xml` is already updated.
- `settings.json` carries over transparently — the
  `gated_deployment` value is accepted as an alias.
- HTTP API: any external scripts that hit `/api/gate/*` need to
  switch to `/api/queue/*`. The JSON envelope key is `entries`
  instead of `gates`.

docs/NEXT_PHASE.md

@@ -1,6 +1,6 @@
 # Phase 6 — recommendations
 
-The v0.2.0 cut leaves PXEForge in a state where the entire protocol stack
+The v0.2.0 cut leaves OpenPXE in a state where the entire protocol stack
 and operator UI are exercised by 66 automated tests, the container is
 multi-arch buildable, and the image ships at ~97 MB. What's left before
 this looks and feels like a 1.0 product is mostly **real-hardware
@@ -66,7 +66,7 @@ serve-side per request.
 ### 5. Wake-on-LAN trigger
 
 A natural pair with per-MAC host bindings: bind a MAC to an image,
-then click "Wake & Image" to send the magic packet and let PXEForge
+then click "Wake & Image" to send the magic packet and let OpenPXE
 do the rest. Implementation is small (`udp/9` broadcast, magic packet
 construction) but it makes the bound-host workflow feel instant.
 
@@ -113,10 +113,10 @@ for silent breakage.
 
 ### 11. Multi-replica deployment
 
-The current design assumes one PXEForge per broadcast domain. Two
-proxies on the same L2 will race; the gate queue is in-memory, etc.
+The current design assumes one OpenPXE per broadcast domain. Two
+proxies on the same L2 will race; the deployment queue is in-memory, etc.
 For HA we'd need to:
-- Externalize the gate queue (Redis, etcd) or lean into "the menu is
+- Externalize the deployment queue (Redis, etcd) or lean into "the menu is
   cheap to refetch if a replica dies";
 - Ensure DHCP proxy replies are deterministic so a client always
   gets the same answer regardless of which replica replied;
@@ -128,7 +128,7 @@ asking for it.
 ### 12. Pi 4 / SBC quirks
 
 Raspberry Pi netboot uses a specific DHCP option-43 vendor field +
-TFTP path layout that PXEForge doesn't currently special-case. There's
+TFTP path layout that OpenPXE doesn't currently special-case. There's
 a spec; the work is small once we have a Pi to test on.
 
 ## What I'd skip
@@ -137,7 +137,7 @@ a spec; the work is small once we have a Pi to test on.
   abstraction; full DHCP would need raw sockets + a lot of corner-case
   handling for problems no operator wants us to solve.
 - **A pluggable backend abstraction à la Tinkerbell.** Tinkerbell does
-  it because they integrate with k8s CRDs. PXEForge's "the file system
+  it because they integrate with k8s CRDs. OpenPXE's "the file system
   IS the database" model is simpler and good enough for the target
   audience. Don't add a Backend trait until something asks for it.
 - **Multiple language UIs.** Bootimus added these in v0.1.62 and the
@@ -148,8 +148,8 @@ a spec; the work is small once we have a Pi to test on.
 
 - Add a Grafana dashboard JSON to `deploy/grafana/` driven off the
   new `/metrics` endpoint.
-- A `pxeforge bench` subcommand that runs a 10-second internal load
-  test (synthetic gate joins) so an operator can sanity-check tuning.
+- A `openpxe bench` subcommand that runs a 10-second internal load
+  test (synthetic queue joins) so an operator can sanity-check tuning.
 - Ship a basic `docker-compose.yml` for the Unraid path that demos
   the new themes / progress widget.
 - Generate a printable single-page operator runbook from the README