[Feature]: Add support for grouping multiple repositories into Packages

### Problem or use case

## Summary

Allow users to group multiple repositories together in Orca and have Orca prepare a local working environment with all of them, similar to how Workspaces worked in VS Code.

## Use case

This would be especially helpful when working on features that require changes across multiple repositories. Instead of manually cloning each repo, creating branches one by one, and keeping them organized separately, Orca could automate the setup and keep the repositories grouped under the same package.

Today, when a feature spans multiple repos, the user has to:

- Manually clone each repository.
- Create or check out the working branch in each one.
- Track which folders belong to the same logical change.
- Re-do this setup every time, on every machine.

There is no first-class concept in Orca for "this set of repos that I work on together as a unit".

### Proposed solution

Add a new concept called **Packages** — a named group of repositories that Orca clones, organizes, and branches together as a single working unit.

> Since Orca already has the concept of Workspaces, this new feature is called **Packages** to avoid confusion.

## Proposed behavior

1. The user can create a new group of repositories (a Package).
2. The user can select multiple repositories to include in that group.
3. Orca clones each selected repository.
4. Orca creates a dedicated folder inside the Orca directory for that group.
5. Inside that folder, Orca places all selected repositories.
6. Orca creates or checks out a branch for each selected repository.
7. The user can then work across all repositories as part of the same grouped context.

## Example folder structure

```
Orca/
Packages/
my-package/
repo-a/
repo-b/
repo-c/
```

## Expected outcome

A user should be able to:

- Create a Package.
- Select multiple repositories.
- Have Orca automatically clone them into a dedicated folder.
- Have Orca create or check out the required branch for each repository.
- Work across all repositories as part of the same grouped context (open files, run agents, search) without manual setup.

## Acceptance criteria

- [ ] User can create, rename, and delete a Package.
- [ ] User can select N repositories (from accessible orgs/accounts) to include in a Package.
- [ ] User can specify (or accept a default of) the branch name to create / check out for each repository in the Package.
- [ ] On creation, Orca clones each selected repository into `Orca/Packages///`.
- [ ] On creation, Orca creates the branch in each repo if it doesn't exist, or checks it out if it does.
- [ ] User can re-open a Package later without re-cloning (Orca detects existing local copies).
- [ ] User can add or remove repositories from an existing Package.
- [ ] Errors per-repo (auth failure, missing branch, dirty working tree) are surfaced clearly without aborting the whole Package setup.

### Alternatives or additional context

## Alternatives considered

1. **Reuse the Workspaces concept.** Could overload "Workspace" to mean a multi-repo group, but Workspaces already has a meaning in Orca / VS Code — overloading it would be confusing. A new name (Packages) keeps the mental model clean.
2. **Manual scripts per developer.** Each user writes a shell script to clone + branch a set of repos. Works today, but is not shareable and not first-class in Orca's UI.
3. **Submodules / monorepo conversion.** Heavy, invasive, and not always feasible across organizations or teams.

## Additional context

- A Package definition (name, list of repos, default branch name) could be exported / imported as a small JSON or YAML file, making it easy for teams to share standard Package setups.
- Could later support "open this Package" deep links and per-Package agent contexts (so an agent run knows about all repos in the Package).
- Each repository inside a Package should still behave like a normal Orca repo (commits, PRs, agents) — Packages are a grouping layer, not a replacement for the per-repo model.