fix(server,web): renaming a grouped project to its repository name sticks#23074

Problem

Renaming a grouped project (one with more than one checkout) to exactly its repository name doesn't stick. Settings and the sidebar snap back to owner/repo. Fixes #15049.

There are two causes. deriveProjectGroupLabel treats a shared title equal to the repository name as a folder default and shows the repository display path instead. And when every checkout's folder title already equals the new name, projectGroupTitleNeedsUpdate skips the save entirely, so nothing reaches the server.

Change

A folder default and a deliberate rename can have the same text, so the client can't tell them apart without help. The server now records whether a title was set by hand.

• Server: projection_projects gains has_custom_title (migration 068, default 0). ProjectStore sets it whenever a project.meta-updated event carries a title. Only explicit renames do that: settings, mobile, and the t3_project_update MCP tool. project.created leaves it false. The flag is derived from existing events, so replay stays consistent and no new event field is needed.
• Contracts: OrchestrationProjectShell.hasCustomTitle is optional, so older servers and cached shells decode as "not renamed", the current behavior. Project shells are sent whole on every update, so web, desktop, mobile, and relay clients get the flag with no other wiring.
• Label (client-runtime, shared by web and mobile): a shared title wins whenever any member has hasCustomTitle. Otherwise the existing rule applies unchanged, so groups nobody renamed still show owner/repo.
• Settings save check (web): an edited name is saved unless every member already has that title and the flag. Untouched blurs are still skipped. Mobile already saves whenever the typed name differs from the label shown, so it needed no change.

I didn't backfill the flag for projects renamed before this change. A previous rename to exactly the repository name never reached the server (it hit the skipped save), so a backfill would recover nothing. Other past renames already display correctly.

Scope and approval

Fixes #15049, which a maintainer triaged and confirmed: triage comment. It states the intended behavior: an explicit rename to the plain repository name should stick, while a folder-default title keeps showing owner/repo.

This replaces #15212, which was closed for its model. Julius's review there asked that the default for never-renamed groups be preserved rather than changed. That's why this uses a stored flag instead of dropping the repository-name check.

Verification

Focused tests, run on unfixed code first and failing for the expected reasons, then passing with the fix:

• projectGrouping.test.ts: two checkouts titled t3code show T3 Code (the repository display name) by default and t3code once renamed (fails on main: expected 'T3 Code' to be 't3code').
• ProjectStore.test.ts: hasCustomTitle stays false after create and a non-title update, and turns true after a title update (fails on main: expected undefined to equal false).
• ProjectSettingsPanel.logic.test.ts: renaming to a title every member already has still saves when the flag is missing, and is skipped once every member has it.

vp run check:changed passes after rebasing onto main: format, lint, knip, typecheck of 29 packages, and 9 test files, including the migration manifest test.

Manual, in an isolated dev server (vp run dev --no-seed, worktree-local state). The fixture is two checkouts in folders named demo, both with origin = https://github.com/acme/demo.git, so each folder title equals the repository name. In Settings → Project, I set Name to demo and blurred the field, then reloaded the page.

Before, on unfixed code: the header stays acme/demo while the field shows demo, and after a reload the field snaps back to acme/demo.

After, on this branch, with the same database upgraded in place by migration 068: before the rename the untouched group still reads acme/demo, so the default is preserved. After the rename, the header and field both read demo, and they still do after a reload. The projection shows has_custom_title = 1 on both demo checkouts and 0 on an untouched project.

Not checked: a native mobile run (mobile uses the same label helper and is covered by the shared tests), and two separate environments (I used two checkouts in one environment, which takes the same grouping path).

Built with Claude Opus 5.5 via Claude Code, running in T3 Code.