Project pickers label by directory basename alone — grouping, contextual labels, or a displayName

Use case: I run one long-lived project as several related git repos, each its own Claude Code project — for example a rover program shaped like:

robotics/rover/planner
robotics/rover/firmware/arm
robotics/rover/firmware/gripper
robotics/rover/firmware/telemetry

The problem: every surface (CLI /resume picker, desktop sidebar, web) labels a project by directory basename alone. "planner" or "arm" carries no context against unrelated projects — a session group called "planner" could belong to any project on the machine. The only workaround is stuffing the path into the basename (robotics/rover/firmware/rover_firmware_gripper), which is redundant on disk, or flattening the tree so names can carry the hierarchy — either way the filesystem is being contorted to compensate for the label.

Asks, any one of which would solve it (in preference order):

1. Grouping: let related projects form a set in the pickers/sidebar — ideally inferred from path hierarchy (group by common parent directory), so robotics/rover/* nests naturally, with firmware/* as a subgroup.

1. Contextual labels: show enough trailing path segments to disambiguate — "rover/planner" and "firmware/arm" instead of bare basenames. Even a fixed "parent/basename" would remove most ambiguity.

1. Display name: a per-project displayName in .claude/settings.json that the pickers honor. Simplest to ship; puts the naming burden back on the user but at least decouples the label from the directory name.

Prior requests in this area were all closed by the stale-bot without resolution — filing fresh per its instruction on #51228 (two-level hierarchy; see also #22617 session folders/pinning, #56067 sidebar grouping, #35431 workspaces). This report adds the concrete failure mode those imply: users renaming/flattening real directory structures because the basename is the only durable label.