TUI token `git.worktree` resolves at runtime but fails config validation

[FallDownTheSystem]

formatGitParts gained a worktree key in #95, and addParts publishes every key it returns as a template token, so {git.worktree} resolves correctly at runtime. But SEGMENT_PARTS.git in src/tui/types.ts was never updated to list it, and isValidSegmentRef validates segment.part references against that table. A grid cell referencing git.worktree is therefore rejected at config load even though the token works.

My own oversight in #95.

Reproducing

Against published 1.29.0:

import { isValidSegmentRef, SEGMENT_PARTS } from '@owloops/claude-powerline/browser'

isValidSegmentRef('git.working')   // true
isValidSegmentRef('git.worktree')  // false

SEGMENT_PARTS.git
// ["icon","headVal","branch","status","ahead","behind","working","head"]

Yet the token resolves fine. Passing gitInfo.isWorktree: true through resolveSegments:

git.icon         "⎇"
git.headVal      "⧉ main ✓"
git.branch       "main"
git.status       "✓"
git.working      ""
git.worktree     "⧉"
git.head         "⧉ ⎇ main ✓"

So this fails to load with unknown segment name "git.worktree":

{ "display": { "tui": { "breakpoints": [
  { "minWidth": 0, "areas": ["git.worktree git.branch"], "columns": ["auto", "1fr"] }
] } } }

Scope

Only direct grid cells are affected. validateGridConfig is the sole caller of isValidSegmentRef (src/config/loader.ts:347). Title and footer tokens go through resolveTitleToken, and segment template items resolve local part names, neither of which checks SEGMENT_PARTS. So "title": { "left": "{git.worktree}" } already works today.

Fix

Add "worktree" to SEGMENT_PARTS.git (src/tui/types.ts:72).

Worth a test alongside it that walks every key formatGitParts returns and asserts isValidSegmentRef accepts it. The two lists silently drifting is the actual bug, and nothing currently catches it. The same shape would cover the other segments, which have the same exposure.

Downstream

powerline-studio drives its TUI token picker straight off SEGMENT_PARTS, so it cannot offer the token until this lands. Deliberately not worked around there, since studio would then be able to emit configs the CLI rejects.