bug: `submit stage --base` defaults to the literal "main" instead of the repo's default branch

[bdelanghe]

Description

prx submit stage hardcodes its base branch to the string main, in two places:

// packages/prx/src/pr-state/cli.ts:5521
base: { type: "string", default: "main" },

// packages/prx/src/pr-state/cli.ts:5543
baseRef: typeof values.base === "string" && values.base.length > 0 ? values.base : "main",

Against a repo whose default branch is not main — master, trunk, develop — the base is simply the wrong branch, or the ref does not resolve at all and staging fails.

Relationship to #119 / #1037

#1037 fixed how a named base branch resolves to a commit: it now takes the merge base with the branch's remote-tracking ref rather than the stale local ref. That fix is correct for whatever branch you name, and it does not help here, because this is about which branch gets named in the first place when the operator does not pass --base. Worth stating explicitly so this is not mistaken for a regression from that change — the hardcode predates it and #1037 neither introduced nor addressed it.

Two things make this look like an oversight rather than a decision

1. A sibling command in the same file disagrees. ~200 lines away, another parser defaults the same flag differently:

   // packages/prx/src/pr-state/cli.ts:5740
   base: { type: "string", default: "origin/main" },

   So two commands in one file default --base to two different values, and neither is derived.

2. The repo already knows how to infer this. packages/prx/src/pr-state/repo_adopt.ts has inferDefaultBranch(), and the repo registry carries a default_branch field per repo (repo_adopt.ts:21, 95, 148). cli-format.ts:1029 already renders origin/${result.defaultBranch} for the worktree view. The capability exists and this path does not use it.

Suggested shape

Resolve the default from the repo rather than assuming it — the registry's default_branch when the repo is adopted, else inferDefaultBranch(), else fall back to main so nothing regresses for the common case. An explicit --base keeps overriding everything, unchanged.

Whatever is chosen, the two sibling defaults should be reconciled or their difference explained, since right now the file asserts both.

Acceptance Criteria

• submit stage with no --base stages against the repository's actual default branch, verified on a fixture repo whose default branch is not main (a real-git test in test/submit/stage.test.ts can build one — the fixtures added by fix(submit): base the staged patch on the merge base with origin/main #1037 already construct repos with real remotes and can be parameterised).
• An explicit --base still wins.
• The main / origin/main sibling defaults in cli.ts are reconciled, or the difference is documented at both sites.