Folder-import follow-ups: grouped nested-import group handoff fix; Mission folder-import UX

## Context

#9491 adds Missions as a task-scoped multi-repo workspace model and intentionally keeps its scope to workspace lifecycle hardening. During review we agreed not to grow that PR with new import UX and to land the folder-import work as focused follow-ups. This issue tracks the two follow-up PRs and records the design decision made for Mission membership.

## Part A — fix: grouped nested-import handoff drops the created group

Independent of #9491; based on latest `main`.

When Add Project scans a folder with multiple git repositories and the user picks **"Yes, import as group"**:

- The main process creates the project group(s) and returns the root group in `ProjectGroupImportResult.group` (`projectGroups:importNested` in `src/main/ipc/repos.ts`, resolver in `src/main/project-groups/nested-repo-import.ts`).
- The renderer handoff ignores `result.group` entirely: `useAddRepoNestedImportFlow.handleImportNestedRepos` completes with only the first imported repo id.
- In hosted mode (Add Project nested inside the workspace composer, #9397), `AddRepoDialogHostedController.onProjectAdded(repoId)` runs `selectAddedProjectRepo`, which deliberately clears any folder-group target (`setSelectedProjectGroupId(null)`) before selecting the single repo.

**Result:** the user explicitly imported the folder as a group, but the composer ends up targeting the first repo ("Create worktree") instead of the group's folder-workspace target. The group that was just created has to be re-found manually in the project combobox. No surface consumes `result.group` today.

**Repro**

1. Open the new-workspace composer → project picker → Add Project.
2. Browse to a local parent folder containing 2+ git repos → nested-import step appears.
3. Click "Yes, import as group".
4. Composer selects only the first imported repo; the newly created group is not selected.

**Fix direction (PR A):** hand the created root group through the completion path. In hosted mode the composer should select the project-group target (the same selection path as `handleProjectChange`'s `project-group:` branch — the imported root group qualifies because nested imports set `parentPath`). Keep the current first-repo handoff as the fallback when no group was created ("import separately", or group creation failed). The sidebar (store-modal) default-checkout handoff keeps its current behavior.

## Part B — Mission folder-import UX

Blocked on #9491.

`MissionCreateDialog` currently offers eligible repos as a flat list with per-group bulk select. Follow-up UX: let the user pick a folder, scan it for nested repositories (reusing the existing nested-import scan), import any repos that are not yet Orca projects, and select the results as Mission members in one flow.

**Decided design constraint:** a Mission stores only the **`repoIds` snapshot taken at selection time** — never a project-group id. Project groups mutate independently (membership, nesting, deletion), and Mission membership must not re-resolve through a group reference after creation.

## Sequencing

1. PR A from latest `main` (no dependency on #9491).
2. PR B after #9491 merges.