refactor(http): resolve registry repos from AppState.project_file_path, not process cwd

[aroff]

Closes the Low-severity follow-up noted in #216.

Problem

The /registry/* handlers resolved the project's [tool.fastskill].repositories config from process cwd (get_repository_manager called std::env::current_dir() → resolve_project_file on every request), ignoring its _service arg — unlike manifest.rs/skills.rs, which use AppState.project_file_path. That inconsistency is why the registry_skill_versions_* tests had to serialize on a global DIR_MUTEX and set_current_dir.

Change

• get_repository_manager(project_file_path: &Path) now loads the manifest directly from the path, resolved once at serve startup into AppState.project_file_path (via load_project_config, which already walks up the tree and canonicalizes). All 6 call sites pass &state.project_file_path.
• Behavior-preserving: AppState.project_file_path is the same walked-up file the old cwd resolution would have found, so no change in which config is read — but request handling no longer depends on (or reads) process cwd, and stays correct even if the process cwd changes after startup.
• Tests: dropped the DIR_MUTEX/DirGuard/set_current_dir scaffolding in the three registry_skill_versions_* tests; they now write the repo config to the fixture's absolute project_file_path. The version tests are now parallel-safe. DIR_MUTEX/DirGuard remain used elsewhere, so their defs are untouched.

Testing

cargo fmt + clippy -D warnings + full cargo test --workspace green; the three registry-version tests pass without cwd serialization.

Reviewed by hand (single-file cohesive refactor — implemented by one sonnet agent, reviewed directly rather than by a review agent).

🤖 Generated with Claude Code