docs: update for new crate layout

crates/application/src/users/get_federated_profile_stats.rs

@@ -1,5 +1,5 @@
 //! The federated half of the former `get_profile` (ADR-0004's closed wart).
-//! `build_federated_profile_response` (`handlers/users.rs`) calls this with a
+//! `build_federated_profile_response` (`http-axum/src/api/user_profile.rs`) calls this with a
 //! synthetic `user_id` that has no row in the local `users` table — a federated
 //! actor's identity is built entirely from the resolved `FederatedProfile`, so
 //! this type carries no `identity` field at all: the old `get_profile` computed

crates/application/src/users/get_page_viewer.rs

@@ -1,10 +1,10 @@
 //! Backs page-chrome data: the nav bar's email/admin state and pending-follow
-//! badge. Absorbs `handlers/helpers.rs::build_page_context`'s inline user lookup
+//! badge. Absorbs `html/helpers.rs::build_page_context`'s inline user lookup
 //! and pending-follower count.
 //!
 //! **Error policy (deliberately no internal tolerance):** this function
 //! propagates every error from `user` and `follow_graph` with `?`. It does not
-//! itself decide to degrade — that's a presentation-layer policy
+//! itself decide to degrade — that's a http-adapter policy
 //! (`build_page_context` logs a warning and falls back to a zeroed `PageViewer`
 //! on `Err`). Page chrome degrading is a rendering decision, not a domain one.
 

crates/application/src/users/resolve_username_to_id.rs

@@ -1,4 +1,4 @@
-//! Absorbs `handlers/users.rs::get_user_by_username`'s
+//! Absorbs `http-axum/src/html/users.rs::get_user_by_username`'s
 //! `repos.user.find_by_username()` call. `None` means "no such username" — the
 //! handler turns that into a 404, same as it always has; this is not an error
 //! condition.