[Feature]: Show multiple MRs/PRs per worktree in the right panel (stacked layout)

[NathanDai5287]

Problem or use case

Orca links exactly one MR/PR to a worktree — linkedGitLabMR, linkedPR, linkedBitbucketPR, etc. are all singular scalar fields, auto-detected from the branch, and the right-side panel shows that single MR. There is no --pr/--mr setter and no array form (orca worktree set only exposes --issue / --linear-issue).

But a single feature often produces more than one MR:

• The same branch/feature is split into several MRs (e.g. a backend MR + a frontend MR that ship together).
• A stack of MRs where B depends on A, C depends on B — I want to see the whole stack in one place, not one card per node.

Today I can't associate those MRs with a single worktree, and the panel can only surface one of them. So the panel under-represents what the worktree actually is.

Proposed solution

• Allow a worktree to carry more than one linked MR/PR (make the linked-MR field a list, or add an explicit attach path).
• Render them in the right panel as a stacked layout — an ordered list of MR cards for the feature, each with its own status (open/merged/draft, checks, reviewers).
• Keep auto-detection for the branch's own MR, but let additional MRs be attached (CLI flag and/or UI), e.g. orca worktree set --add-mr <url> (repeatable).
• Provider-neutral: works for GitLab MRs and GitHub/Bitbucket/etc. PRs, not just one.

Alternatives or additional context

• Current workaround is worktree lineage (orca worktree create --parent-worktree <selector>), but that makes one card per MR rather than one panel aggregating the feature's MRs — different mental model from "this feature has these N MRs."
• The other workaround is attaching each MR URL to the shared Linear issue (orca linear attach --current --url <mr-url>), but those surface inside the Linear issue's attachments, not Orca's own MR panel, and aren't a stacked display.
• Related but distinct existing issues — this one is specifically about the right panel aggregating and displaying multiple MRs for one worktree, not restacking mechanics or cross-workspace dependency graphs:
  • [Feature]: PR dependency awareness (stacked PRs / PR tree), read-only via external tools #7915 — PR dependency awareness (stacked PRs / PR tree), read-only via external tools
  • [Feature]: multi-repo work driven by agent-managed worktrees and stacked PRs #7918 — umbrella: multi-repo work driven by agent-managed worktrees and stacked PRs
  • [Feature]: Add Branch Visibility and Controls for Graphite Stacks #6368 — Branch visibility and controls for Graphite stacks
  • [Feature] Stacked PRs, with stacked worktrees #8875 — Stacked PRs with stacked worktrees (closed, not planned)