feat(sidebar): group projects as plain labels or folder anchors

[wzz6423]

Summary

• Sidebar projects can be organized into collapsible groups via the new sidebar "+ group" button: plain groups (pure labels) or folder groups anchored to a local folder
• Plain groups: new sessions opened from the group start in ~; folder groups: they start in the anchored folder — new tabs in projects placed inside also start there
• Group headers support click-to-collapse, double-click rename, and a context menu (New Project in Group / Rename / Change Folder for folder groups / Remove Group); rows gain a Move to Group submenu
• Group membership (groupID) and group list both survive relaunch (session snapshot + project-groups.json beside the app config, Debug/Release separated)
• zh-Hans + ja localizations for all new strings

Validation

• Built and driven via AX automation on the Debug app:
  • New Group menu → Plain Group created, default name localized, JSON persisted
  • Folder group restored from JSON after relaunch (icon/name/path)
  • Project moved into a folder group renders indented under the header, count updates, ungrouped rows keep ⌘ indexes
  • New session in a folder-grouped project starts in the group's folder (tab shows ~/个人/code/zshell/mac)
  • Collapse toggle persists (isCollapsed) and re-expands
• make update full build passes

[github-actions]

Automated reply: the following guidance comes from CONTRIBUTING.md.

Thank you for opening a pull request. Check these requirements while it is awaiting review.

• The PR title must use an English Conventional Commit subject, for example:

  • feat(terminal): add per-pane scrollback search
  • fix(git): resolve stale diff after a branch switch
  • docs: update contributing guidelines
    Allowed types are feat, fix, docs, style, refactor, perf, test, chore, build, ci, and revert.

• The PR body must be in English and contain the Summary, GitHub Project, PR Type, Validation, Risk and Rollback, Related Issue, and AI Attribution sections that .github/PULL_REQUEST_TEMPLATE.md provides.

  • GitHub Project keeps the template value - Project: zshell Development. Project Automation reads it to place the pull request on the shared board.
  • PR Type declares exactly one - Type: value, and it must match the type in the title. PR Automation turns it into a label, for example fix into bug.
  • Every Validation block must declare passed, failed, or not run. passed and failed need Command and Result; not run needs Reason.
  • Related Issue must either close an issue with a keyword such as Closes #123, which also applies the development label, or be exactly None.
  • AI Attribution must declare - Agent:. Any agent other than None requires a matching - Co-authored-by: Name <email> line, which must also appear as a trailer on at least one commit, and applies the ai-assisted label.

  Example:

  ## Summary
  - Add a repository hygiene check.
  
  ## GitHub Project
  - Project: zshell Development
  
  ## PR Type
  - Type: ci
  
  ## Validation
  - Status: passed
  - Command: bash .github/scripts/check-repository-hygiene.sh
  - Result: Repository hygiene check passed.
  
  ## Risk and Rollback
  - Risk: Only repository automation is affected.
  - Rollback: Revert this pull request.
  
  ## Related Issue
  Closes #123
  
  ## AI Attribution
  - Agent: Claude Code
  - Co-authored-by: Claude <noreply@anthropic.com>

• The PR Quality check validates this format; a pull request cannot be merged while the check is failing. PR Automation then applies the labels and assigns the pull request.

• There is no unit test target: app changes are proven by building and running Zshell and exercising the change, so say in Validation what you did and attach screenshots or a recording for UI work. Run cargo test --locked in mac/Vendor/alacritty-bridge for bridge changes, bun run typecheck && bun run build in web/ for site changes, and bunx tsc --noEmit in mac/ for anything under mac/scripts/. Install dependencies with bun install --frozen-lockfile in each package before running Bun checks.

• Build all new UI in AppKit. SwiftUI is legacy and must not be introduced or expanded; materially changing an existing SwiftUI view means migrating the affected UI to AppKit.

• Update the relevant documentation when changing user-visible behavior, build instructions, or the release process. CHANGELOG.md is written for end users, so it records the shipped outcome rather than the fixes and refactors on the way there, and the version is bumped only by a release, never by a pull request.

• Do not commit mac/build/, mac/Vendor/alacritty-bridge/target, node_modules, dist, downloaded files, logs, tokens, signing materials, or personal data. Repository Hygiene fails on them.

• main and publish-v* are protected and can only be updated through a reviewed pull request that passes its checks.