Add e2e CI matrix exercising pack + marketplace against the real APM CLI

Follow-up from apm-review-panel on #40 (https://github.com/microsoft/apm-action/pull/40#issuecomment-4477106145).

Why

PR #40 adds five new pass-through inputs (marketplace, marketplace-path, json-output, offline, include-prerelease) plus a misuse-rejection branch and a workspace-containment check. All of it is covered by unit tests against a mocked @actions/exec. None of it is covered by an actual apm pack invocation in CI.

The current alpha / beta / gamma matrix in .github/workflows/test.yml runs the installer path against a real CLI, but it does not exercise the new pack inputs end-to-end. So a real-CLI regression on flag names, exit codes, or stdout shape could ship without us seeing it until a downstream consumer files a bug.

What to add

A new job (or extension of the existing pack matrix) that:

1. Installs the released APM CLI (microsoft/apm-action@v1 setup-only mode, or pinned binary).
2. Scaffolds a tiny fixture covering each new input:
   • single-plugin (current default path)
   • marketplace-only project with outputs: map (marketplace: 'auto', json-output: 'reports/pack.json')
   • hybrid (plugin + sibling marketplace)
3. Asserts:
   • the action produces the right artifact set for each fixture
   • bundle-path output is empty exactly when expected (marketplace-only)
   • marketplace-path overrides land where requested
   • the misuse-rejection branch fails with a useful message when marketplace is used on a single-plugin project
   • --offline and --include-prerelease reach the CLI (assert via apm pack --json shape if possible)

Why this is a separate issue, not part of #40

Adding a real-CLI matrix is non-trivial: it needs a fixture catalog, a CLI install step, and probably a separate workflow file. Doing it inside #40 would balloon the PR diff and gate the v1.8.0 tag on infrastructure work that does not change the action's behaviour. The pass-through inputs themselves are mechanical (5 flag forwards + 1 validation branch) and covered by the unit suite; the e2e matrix is an additional confidence layer, not a correctness gate.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

Start by reading the existing alpha/beta/gamma matrix in .github/workflows/test.yml and the context from PR #40. Add a real-CLI pack matrix with the three requested fixtures, then verify artifact sets, bundle-path behavior, marketplace-path overrides, misuse rejection, and offline/include-prerelease handling against the stated acceptance checks.