Blocking / must-fix before merge to main

1. Unpinned actions/checkout@v6 violates the repo's own action-pinning rule.
   - uses: actions/checkout@v6
   AGENTS.md §6 requires pinning actions to a full commit SHA with a trailing # vX.Y.Z comment, never a moving tag. The other two actions in this same file are correctly pinned (setup-rust-toolchain@166cdc… # v1.17.0, peaceiris@84c30a… # v4.1.0), and the dominant convention across ci.yml/release.yml/nightly.yml is actions/checkout@df4cb1c # v6.0.3. Match it here for consistency and supply-chain safety. (There are pre-existing @v6 stragglers elsewhere, but a new file shouldn't add another.)

2. The temporary feature-branch trigger must be removed before merging.
   branches: [docs/demo-screencasts]
   The inline comment already acknowledges this is scaffolding ("The feature-branch push trigger is temporary"). It's dead weight on main and, combined with the commit eb4edea ci: trigger demo render on feature branch, is exactly the kind of dev-loop churn the OSS workflow (§11: "one logical change") says to clean up. Drop the push: trigger (and squash the scaffolding commits) as part of the pre-merge rebase you noted.

3. Misleading comment in the "Stage rendered media" step.

demo-gifs.yml
Lines 55-61
      # Publish from an unignored staging directory. `docs/media/*.gif` is
      # intentionally git-ignored on source branches, and the Pages action honors
      # that ignore file while preparing assets.

peaceiris/actions-gh-pages publishes publish_dir (./rendered-media) with force_orphan; it does not consult docs/media/.gitignore. The staging copy is needed precisely because docs/media is git-ignored — the "Pages action honors that ignore file" clause is inaccurate and could mislead a future maintainer. Reword to just explain the staging copy.

4. Fictitious model id shown in a user-facing demo. Qwen/Qwen3.5-0.6B (in cli.tape, rocm-demo-env.rs, demos.rs) isn't a real model — Qwen3.5 has no 0.6B variant, and it's not in model_catalog.json (which has Qwen/Qwen3.5-4B). It works because the mock advertises whatever it's told, but a reviewer/user watching the GIF may notice. Consider using a real catalog id (e.g. Qwen/Qwen3.5-4B) so the screencast doesn't teach a non-existent model. Purely cosmetic, but it's the visible artifact this PR exists to produce.

Nits (optional)

• PR description drift. The description says "four demos (version, engines list, services list, one-shot chat)" and per-command tapes; the implementation consolidated to two composite tapes (cli, console). Worth syncing the description so reviewers aren't hunting for four tape files.
• rocm-demo-env standalone reply. When run directly (as demos.md/demo-env.sh suggests for manual testing), ROCM_MOCK_CHAT_REPLY is unset, so rocm chat returns the test stub rather than the natural reply — only xtask demos sets it. Fine, but the manual-run docs could mention exporting it if you want the realistic reply.
• README lands with 404 image links until the workflow runs once. Acknowledged inline. Since the release trigger is the first realistic fire, consider a one-time manual workflow_dispatch right after merge so main's README isn't broken in the interim.

Addressed the review in 3523dc3:

• pinned actions/checkout to the full v6.0.3 SHA;
• removed the temporary feature-branch trigger;
• corrected the generated-media staging explanation;
• replaced the fictional model identifier with catalog entry Qwen/Qwen3.5-4B everywhere;
• documented ROCM_MOCK_CHAT_REPLY for direct helper runs; and
• updated the PR description for the two composite CLI/Console demos and the now-merged test: add BDD E2E tests with cucumber-rs #69 dependency.

I left the existing commits intact because this repository squash-merges PRs, so the temporary scaffolding commits will not enter main; rewriting after review would only add force-push churn.

The full pre-push suite passes after a clean rebuild: YAML validation, formatting, clippy, workspace tests, license checks, and signature/sign-off verification. CodeQL alerts 716 and 717 were independently security-reviewed and dismissed as false positives; their threads remain open for re-review.

After merge, the workflow should be dispatched once from main so the README media remains immediately available before the next release trigger.