refactor: presentation becomes http-axum adapter, absorbs templates

CONTRIBUTING.md

@@ -43,13 +43,13 @@ The project follows hexagonal (ports & adapters) architecture. See `architecture
 
 **Key rules:**
 - Presentation handlers never touch repositories directly — all domain logic goes through use cases in the `application` crate
-- Application use cases return raw domain data — URL formatting, date display, and view model assembly belong in presentation mappers (`presentation/src/mappers/`)
+- Application use cases return raw domain data — URL formatting, date display, and view model assembly belong in presentation mappers (`crates/adapters/http-axum/src/mappers/`)
 - Use cases called from presentation handlers take a `&FooDeps` struct (registered in `application::Deps`, built by `bootstrap::build_deps`) — never `&AppContext` itself, which `application` cannot even depend on. A few keep individual `Arc<dyn Trait>` params instead: `enrich_movie` and `request_enrichment` because they are called from adapters rather than handlers, and `diary::log_review` because its one extra dependency comes from `Services` rather than a repository. `wrapup::compute`, `import::cleanup` and `integrations::cleanup` also take individual params, but they are only ever called from jobs. See ADR-0007 for the exact list and why each is legitimate
 
 ```
 domain         → pure types, traits (ports), zero deps
 application    → use cases, orchestration
-presentation   → Axum handlers, routes, OpenAPI
+http-axum      → Axum handlers, routes, OpenAPI
 worker         → event consumer, background jobs
 adapters/*     → implements domain ports (sqlite, AP, etc.)
 spa/           → React SPA (TanStack Router + shadcn/ui)