refactor(app): share deep link project opening

[anduimagui]

Issue for this PR

Closes #43472

Related to #40094. That issue also covers stale project records after a repository is moved.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This adds useOpenProject. The hook checks the project list and asks the server to recognize an unknown directory before it opens the project.

It also adds useDeepLinks. This hook owns the pending links, desktop event listener, route creation, and project-open sequence.

Both layouts now use the same hooks. The legacy layout keeps its session handoff and worktree normalization through hook options.

How did you verify your code works?

• bun typecheck in packages/app
• bun test src/pages/layout/helpers.test.ts in packages/app (27 tests pass)
• git diff --check

Screenshots / recordings

Not applicable. This changes project recognition and navigation behavior without changing the UI.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

If you do not follow this template your PR will be automatically rejected.

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Nice extraction — the shared hooks remove real duplication between layouts and the enabled() gating keeps legacy/new handling mutually exclusive. A few things to tighten:

• packages/app/src/pages/layout/open-project.ts:20-22 — The registration call swallows all errors (.catch(() => undefined)) and then unconditionally proceeds to open() and navigate. Why it matters: a failed project.open (bad path, permission error) leaves the user staring at a project view backed by nothing, with zero feedback — worse than the old fire-and-forget because the await signals intent to care about the result. Suggestion: return/propagate failure, skip navigation, and surface a toast.

• packages/app/src/pages/layout/use-deep-links.ts:24-38 — Neither .then chain has a .catch. If openProject rejects (e.g. options.open throws synchronously inside ensureProject), navigation is silently dropped and the rejection becomes unhandledrejection noise. Suggestion: add .catch with at least a log, or make handleDeepLinks async with try/catch.

• packages/app/src/pages/layout/use-deep-links.ts:23-39 — Multiple links in one event now complete in arbitrary async order, so the final route depends on resolution order (a slow open-project link can land after a new-session link and override its navigation). Pre-existing ambiguity made more likely by deferring all navigation behind promises. Suggestion: process links sequentially (await in a loop) or document last-resolved-wins.

• packages/app/src/pages/layout/open-project.ts:17 — The known-check maps directories through options.projectDirectory in the legacy wiring but not in layout-new.tsx, which passes the raw directory. If the new layout's project list keys differ from raw worktree paths (the reason legacy needs projectRoot), known will always be false there and every open pays an extra API round-trip. Suggestion: confirm both lists share the same keying, or apply one canonical mapping inside the hook.

• packages/app/src/pages/layout/open-project.ts:16-25 — Two overlapping triggers (deep link plus manual open) for the same unknown directory both run the registration call. Harmless today, cheap to fix: memoize the in-flight promise per directory.

• Nit: use-deep-links returns { handleDeepLinks } but neither call site uses it; either drop it from the API or keep it deliberately for tests.

No blocking issues found.

[anduimagui]

Closing this PR and using the clean replacement here instead: #44137.
@Hona @Brendonovich probably worth looking into Enough1122, I found 199 similar comments in a recent sample over about 14 hours.