Restore project registry CRUD from project-access surfaces

[CompleteDotTech]

Problem

Both current project-access surfaces let a human change a familiar's access to already-registered projects, but neither provides a way to manage the registered-project catalog itself:

1. Settings → Familiars → [familiar] → Projects (FamiliarStudioProjectsTab)

   • Lists registered projects and toggles direct grants/read-write access.
   • Its empty state says “Add a project in the Code workspace, then grant it here,” but does not link to or embed a registration flow.

2. Chat → Projects (the per-familiar access matrix introduced by feat(projects): rebuild chats > Projects as per-familiar access matrix (cave-luq4) #3689)

   • Lets users filter projects, cycle None → Read → Full, set access in bulk, and reset grants.
   • It similarly treats the registry as read-only; when empty, it directs the user to register a project from the chat composer.

This makes project access feel like the project-management UI while omitting the expected CRUD controls. A user cannot add, rename, change the root of, or remove a project from either panel.

Evidence / code map

• Settings access-only component: src/components/familiar-studio-projects-tab.tsx
  • Loads /api/projects, /api/project-grants, and /api/grant-proposals.
  • Mutates only /api/project-grants.
• Chat access-only matrix: src/components/projects-view.tsx as rebuilt by feat(projects): rebuild chats > Projects as per-familiar access matrix (cave-luq4) #3689 / 1b23ffa.
  • The rebuild replaced the previous master-detail Projects hub with a permission matrix and deleted its project detail CRUD surface.
• The CRUD capability is already implemented below the UI:
  • POST /api/projects
  • PUT /api/projects/:id
  • DELETE /api/projects/:id
  • useProjects() already exposes createProject, renameProject, updateRoot, updateColor, and deleteProject.

Desired outcome

Give users an obvious, safe way to manage the project registry in the same flow where they manage project access, without conflating project lifecycle with familiar grants.

A small shared “Manage projects” entry point may be preferable to duplicating forms in both access panels. It should be reachable from both surfaces, or each should provide a clear contextual link to the one canonical registry-management surface.

Acceptance criteria

• A user can add a registered project (name + root, including the existing native/in-app directory picker behavior where applicable) without first starting a chat.
• A user can rename a project and update its root from the canonical management UI.
• A user can remove a project through an explicit confirmation flow that explains the effect on familiar access; direct grants should not remain as misleading orphaned UI state.
• Both Settings → Familiar → Projects and Chat → Projects expose a discoverable route into the canonical project-management UI (or provide equivalent CRUD directly).
• Familiar access controls remain distinct and continue to enforce the existing grant protocol; creating a project must not silently grant unrelated familiars access.
• Empty states no longer send users on a hidden, chat-only path to create their first/next project.
• Add focused UI/API tests covering create, edit/root update, delete confirmation, post-mutation refresh, and grant consistency.

Out of scope

• Changing the project root allowlist or permission model.
• Changing the semantics of access groups, supreme-familiar access, or grant-proposal approval.
• Reintroducing the deleted full Projects hub wholesale unless that is the cleanest implementation path.

Reproduction

1. Open either pictured project-access panel.
2. Observe existing projects can only be granted/revoked or assigned an access level.
3. Look for an add-project control or an option to rename/change root/delete a project.
4. None is available, despite the backend and useProjects client helpers supporting those operations.