Split awa-api from awa-ui: separate API response types from embedded frontend

## Summary

The `awa-ui` crate currently serves two concerns:

1. **REST API** — axum handlers, response types, application state, error handling
2. **Embedded frontend** — React build assets served via `rust-embed`

These should be separate crates so that:

- API response types (`JobResponse`, queue stats, etc.) are usable independently of the frontend
- The `awa-cli` or other consumers can depend on `awa-api` without pulling in the React build
- API types evolve independently of the DAL layer (`JobRow` from `awa-model`)

## Current Pain Point

The API currently returns `JobRow` (a database row struct deriving `FromRow`) directly to HTTP clients. This leaks the DAL layer into the API contract — adding computed fields like `original_priority` required wrapping `JobRow` in a `JobResponse` struct inside the UI crate.

A `JobResponse` wrapper was added in the jobs handler as a first step, but it belongs in a dedicated API crate with:
- All response types (`JobResponse`, `QueueStatsResponse`, etc.)
- Shared application state
- Error types for the HTTP layer
- Computed field logic (e.g., priority aging reconstruction)

## Proposed Crate Structure

```
awa-api API types, handlers, state, errors
│
▼
awa-ui Embedded React frontend + rust-embed, depends on awa-api
```

## Related

- `JobResponse` wrapper added in `awa-ui/src/handlers/jobs.rs`
- ADR-005 priority aging uses a computed `original_priority` field in the API response