ListWorktrees and placement metadata return empty branch/label for every named branch #2420

Summary

ListWorktrees returns an empty branch and label for every worktree that is on a named branch, and ClearSession/ForkSession placement metadata (and Session.placement) has the same empty branch/label. A client cannot tell which selector is which worktree except by response order and revision, which is ambiguous whenever two worktrees share a HEAD (for example, right after git worktree add -b).

Cause

ListWorktreesForSession (internal/adapter/server/placement_discovery.go:136-137) and canonicalPlacementMetadata (internal/adapter/server/placement.go:924-931) pass Label and Branch through sanitizePlacementDisplay (internal/adapter/server/placement.go:933-951). That function returns "" for any value containing / or \ (a path-leak guard). The local provider sets both from git worktree list --porcelain's branch line, which is always a full ref such as refs/heads/feat, so the guard blanks every named branch. Only "Detached worktree" survives.

Reproduce (offline, at e17d839 and at main f9a3297)

1. git init -b main repo && git -C repo commit --allow-empty -m init && git -C repo worktree add -b feat ../wt-feat
2. mecated serve --mock --trust-project --workspace repo ...
3. Create a session, call ListWorktrees{session_id}.

Observed: {kind:"worktree", label:"", branch:"", revision:<sha>} for all entries. Expected: branch:"refs/heads/feat", label:"refs/heads/feat" (or a short name), as localPlacementProvider.ListWorktrees (internal/app/placement.go:203-213) intends.

Suggested fix

Exempt branch refs from the path guard (for example, accept values that match git check-ref-format under refs/heads/), or strip refs/heads/ before sanitising and return the short name.

Related: #1797 (reattach after HEAD moves), which makes clients re-select worktrees more often.