Add issue proposals for multi-ApiRunner REPL support

[Copilot]

Summary

Breaks down the “Multiple ApiRunners in the REPL” work into actionable issue proposals instead of implementing runtime changes in this PR. The proposals cover grouped REPL context/routes, group-qualified .scenario, and updated tab completion, all linked to the parent issue.

• Proposed issue breakdown
  • Added three proposal files under .github/issue-proposals/:
    • repl-multi-api-context-and-routes.md
    • repl-scenario-command-with-group-qualifier.md
    • repl-tab-completion-for-multi-api-scenario.md
• Parent linkage + metadata
  • Each proposal includes parentIssue: 1893 and consistent labels/metadata.
• Scope
  • This PR adds planning artifacts only (no source/test/runtime behavior changes).

---
title: "repl: add group-qualified .scenario command for multi-API"
parentIssue: 1893
labels:
  - enhancement
  - repl
---

Original Prompt

This section details on the original issue you should resolve

Issue title: Multiple ApiRunners in the REPL

Issue description:
When there are multiple ApiRunners, instead of sending only the first one to the REPL, send all of them and create affordances to use them.

For example, the context object will become a map of contexts keyed by the group name (context.billing, context.inventory, ...).

The .scenario command will take a qualifier (.scenario groupName doSomething)

When there is only one ApiRunner the behavior should remain as it is now -- no qualifier.

Tab completion should be updated to accommodate these changes.

Flesh out a plan to implement these changes and create one or more issues.

Manual acceptance tests

• Repository contains exactly three new files in .github/issue-proposals/ for REPL multi-API context/routes, .scenario qualifier, and tab completion workstreams
• Each new proposal file has valid YAML front matter with non-empty title, parentIssue: 1893, and non-empty body content
• Each proposal includes an observable acceptance-criteria checklist describing expected user-facing REPL behavior
• Merging the PR would allow the issue-proposal workflow to create sub-issues under the parent issue from these files

Tasks

• Added three focused issue proposal documents to split implementation into independent, reviewable work items
• Included parent issue linkage and proposal metadata in all files
• Wrote scoped context, proposed approach, and acceptance criteria for each sub-issue