Feature Request: support multiple repositories in a single session

No files or tests are named. Start by tracing session creation and how repository or workspace roots are represented, then inspect permission enforcement and result reporting. Done means supporting multiple repositories with per-repository access, shared context, explicit resolution failures, and per-repository changes or linked pull requests.

Problem

A session today operates against a single repository working directory. Real changes frequently span more than one repository: a service and its client, a shared package and its consumers, or a target repository plus a separate repository that holds reusable instructions, prompts, and skills.

The only workaround is to start a separate session per repository. Each session has its own context, its own history, and its own result, so the agent cannot reason across the set, validate a change end to end, or produce a coordinated outcome.

What is missing

• No way to declare more than one repository when creating a session.
• No per-repository permission model, so a caller cannot grant read-only access to one repository and write access to another.
• No way to produce linked pull requests, or a combined status and rollback plan, across repositories.

Proposed behavior

• Session creation accepts a list of repositories or workspace roots rather than a single working directory.
• Each entry carries an explicit access level (for example read or write).
• The agent can read, edit, and run validation across all declared roots within one session and one shared context.
• The session can open linked pull requests and report a combined result, identifying which repositories changed and which were read only.
• Repositories that fail to resolve are reported explicitly rather than silently omitted.

Example scenario

A caller asks the agent to trace a failing API call from a consuming application into the library that implements it, fix the library, update the consumer, and run both test suites. This requires both repositories present in one session.

Acceptance criteria

• A session can be created with two or more repositories.
• Access level is configurable per repository and enforced.
• Shared context is retained across all roots for the lifetime of the session.
• The result identifies per-repository changes and any linked pull requests.