feat(projects): projects repo + group owner reads; wire into ApplyService

Read side of §7 ownership, ahead of the claim logic.

- project_repo: `ProjectRepository` trait + `PostgresProjectRepository`
  (list / get_by_id / get_by_slug). Writes are NOT here — a claim registers
  its project via an in-tx upsert (next commit).
- group_repo: `list_with_owner()` LEFT-JOINs projects for each group's owner
  slug (backs `pic groups ls`); columns qualified since id/slug/name exist on
  both tables.
- ApplyService gains a `projects` handle; constructed in the picloud binary.
- tests/projects_repo: round-trip pinning list_with_owner (claimed→slug,
  unclaimed→None) and that ancestors() surfaces owner_project nearest-first —
  the fold input the claim path walks.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/manager-core/src/apply_service.rs

@@ -653,6 +653,10 @@ pub struct ApplyService {
     pub apps: Arc<dyn AppRepository>,
     /// Group lookups (Phase 5): resolve a group slug→id for group/tree apply.
     pub groups: Arc<dyn crate::group_repo::GroupRepository>,
+    /// Project registry (§7 multi-repo ownership): the READ side. The claim
+    /// write path registers projects via `upsert_project_tx` inside the apply
+    /// transaction, not through this repo.
+    pub projects: Arc<dyn crate::project_repo::ProjectRepository>,
     /// Module resolver (Phase 4b): lexical, origin-aware module lookup used by
     /// the single-node dangling-import plan check (§5.5).
     pub modules: Arc<dyn picloud_shared::ModuleSource>,