Suggested test: package/shared-js-module-resources

## Motivation

Link to the gh-aw PR: github/gh-aw#60536 — `aw.yml` package manifests previously rejected `.mjs`/`.cjs` resources targeting `.github/workflows/shared/`, blocking packages from shipping JavaScript helpers alongside shared workflows. This is now supported.

## Proposed test

- **Workflow file**: n/a — this exercises `gh aw` package install/update CLI behavior, not a single `test-*.md` safe-output scenario
- **Trigger**: n/a (would need a `gh aw install`/`gh aw update` CLI invocation, not `workflow_dispatch`)
- **Engine**: n/a
- **Safe output**: n/a
- **Variant**: n/a

## Minimal test prompt sketch

Would require: a package manifest (`aw.yml`) in a fixture repo declaring a `.github/workflows/shared/*.mjs` resource, then running `gh aw install`/`gh aw update` against it in this repo and asserting the shared JS module lands on disk and is importable by a workflow. This does not fit the existing `workflow_dispatch`-based E2E harness pattern (`e2e.sh` tests exercise compiled, already-installed workflows, not the package install/update CLI flow itself).

## New fixtures or secrets needed

Yes — would need a new fixture package repository (e.g. `githubnext/gh-aw-test-package`) containing an `aw.yml` manifest with a `.mjs`/`.cjs` shared resource, since none of the current fixtures (`gh-aw-test`, `gh-aw-side-repo`) model package distribution.

## Notes

Flagging as speculative/out-of-harness-scope rather than proposing a PR. Worth discussing whether `e2e.sh` should grow a separate CLI-level test category (outside the `test--.md` convention) for `gh aw install`/`update`/package lifecycle behavior, since this is the second recent package-lifecycle PR (also #60452 `gh aw update` package-aware targets) without any current E2E coverage.

> Generated by [🔍 Suggest New E2E Tests](https://github.com/githubnext/gh-aw-test/actions/runs/34747998916) · copilot · auto · 71.7 AIC · ⌖ 5.41 AIC · ⊞ 8.4K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-test+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-test%2Fsuggest-new-e2e-tests%22&type=issues)

Review e2e.sh and the existing test--.md convention, then compare the gh-aw-test and gh-aw-side-repo fixtures. Decide with maintainers whether to add a separate CLI-level category for gh aw install/update, and create the needed package fixture only after that scope is settled. Done means install/update coverage asserts that a shared .mjs or .cjs resource lands on disk and is importable.

Written by the indexing model from the issue text.