feat(projects): unify navigation and reviewed channel requests

[thomaspblock]

Summary

• resolve project homes consistently from both channel and project routes
• preserve repository, file, commit, task, and review context when expanding workspace sheets
• add encrypted owner-reviewed project-channel requests for managed agents

This is Part 5 of the channel-first Projects stack, based on #6595. The final part contains overview, aggregation, and visual polish.

Testing

• focused request parsing, project route, home-channel, workspace-sheet, and sidebar tests: 20/20 passed
• ACP tests: 816 passed; CLI tests: 370 passed
• Desktop unit suite: 5,444/5,444 passed
• E2E-mode Desktop build passed
• Rust clippy, TypeScript, Biome, and differential file-size checks passed
• full pre-push gate passed

Post-Deploy Monitoring & Validation

• open the same project home from Channels and Projects, then exercise file/work-item deep links and an agent add-channel request
• healthy signals: identical home surface, preserved repository context, one approval dialog, and no channel before approval
• failure signals: normal channel fallback, wrong repository detail, duplicate requests, or unreviewed channel creation; mitigate by reverting this PR

[jedwards27]

:bot: Jude’s code review agent

Verdict: REQUEST CHANGES

Reviewed e7220100e45a14d90e637da810af20adec916de4..90ffff85ce189da21d3fcb1278add9714212b0f0 at exact clean head 90ffff85ce189da21d3fcb1278add9714212b0f0.

Risk: high — this changes project/channel route ownership and an encrypted, owner-reviewed creation flow carried by ephemeral relay events.

Blocking findings

1. An unrelated project assertion can take over another channel’s route. ChannelRouteScreen renders ProjectChannelHome from findProjectHomeByChannelId (desktop/src/app/routes/ChannelRouteScreen.tsx:136-139,276-285), but that resolver filters only by legacy status, channel ID, visibility, and age (desktop/src/features/projects/lib/projectHomeChannel.ts:5-19). It does not apply the owner/maintainer-backed repository proof already encoded by hasAuthoritativeHomeBinding (:32-45). The project route does apply that proof (desktop/src/features/projects/ui/ProjectDetailScreen.tsx:682-699), so the routes disagree: an unrelated signer can publish a listed kind-30621 with someone else’s buzz-channel and replace that normal channel route with their project chrome, while the equivalent project route refuses it. Existing tests explicitly reject bare/unauthorized bindings (projectHomeChannel.test.mjs:49-75) but the new resolver test omits repository authorization (:83-96).

   Author action: require hasAuthoritativeHomeBinding during channel-route resolution, and add regression cases for bare, unauthorized, and competing authorized/unauthorized assertions.

   Verification owner: author adds the regression; reviewer mutation-checks that removing the gate fails it.

2. A second valid owner-review request is silently and permanently discarded while the first dialog is open. accept records every request ID in seenRequestIds and only afterward returns if pendingRequestId is occupied (desktop/src/features/projects/useProjectChannelRequests.ts:37-55). There is no accepted-request queue; bufferedRequests is only startup trust-data buffering (:31-33,59-67). Dismiss and success merely clear the current ID (:110-115,150-154). Because kind 24200 is ephemeral and the CLI has already reported that the draft was sent for review (crates/buzz-core/src/kind.rs:461-470; crates/buzz-cli/src/commands/projects.rs:61-74), request B cannot be recovered: replay would also be rejected as seen.

   Author action: queue accepted requests and advance after dismiss/success, or implement an explicit rejection/notification protocol. Add a state-machine regression proving A → B → resolve A → B displayed, while duplicate A remains suppressed.

   Verification owner: author adds the regression; reviewer mutation-checks that restoring the early drop fails it.

Validation

• Independent systems/integration and product/UI passes both confirmed both blockers and found no additional material defect.
• Product/UI exact-head evidence before cleanup: full Desktop unit package 5,553/5,553 passed; Desktop TypeScript typecheck passed; cargo test -p buzz-cli passed 379/379 plus one ignored doctest. Systems targeted evidence: projectHomeChannel.test.mjs 7/7, projectChannelRequest.test.mjs 2/2, and useAddProjectChannel.test.mjs 4/4. These green tests do not exercise either blocker.
• Product/UI smoke built the E2E app and reached 206 passes before the local pnpm store/worktree dependency links disappeared (playwright worker entry / playwright-core missing); 891 tests did not run. This is a reviewer-tooling confidence gap, not an author defect or product failure.
• My clean checkout: git diff --check e7220100e45a14d90e637da810af20adec916de4..HEAD passed. A local targeted Node invocation was not executable before dependency installation (ERR_MODULE_NOT_FOUND: typescript), so I do not count it as behavioral evidence.
• GitHub at final refresh: smoke and integration shards reported green; Desktop Core was still in progress. This is not the reason for REQUEST CHANGES.

Manual/native evidence: not run. The blocking ownership and queue defects are established from contract boundaries and source state transitions; native UI proof would not clear them.

Residual risk: dismiss/app-restart recovery remains non-durable for ephemeral requests; approval-dialog focus/keyboard/error/retry behavior was not completed in-browser; no native harness evidence was captured; and the broad workspace/deep-link surface remains unit/source-checked rather than exact-artifact witnessed. Product/UI could not perform a post-test SHA/tree recheck because its checkout was removed during reconciliation, so its commands are attributed to the pinned exact-head worktree used to launch them, not a later cleanliness claim. Any new head requires full delta review.