cli: strengthen mutiny init next-step hint + test coverage

[CodewithJha]

👋 New to open source?
Thanks for considering contributing to Mutiny.
This issue is intentionally beginner-friendly.
If you get stuck, ask questions in the comments.
We're happy to help.

Context

mutiny init already prints a “Next steps” block in packages/mutiny_cli/src/mutiny_cli/init_cmd.py (edit adapter → review policy → optional Hosted → mutiny run). Unit tests assert scaffold files but do not assert the hint text. Step 4 also omits --no-hosted, which newcomers need for CLI-only runs.

Goal

Make the post-init hint unmistakably actionable for a first run, and lock it with a small test assertion.

Why it matters

Scaffold success without a clear “what next” is where many CLIs lose first-time users. A one-line flag mention + test prevents regression.

Acceptance criteria

• Next-step output mentions editing .mutiny/adapter.py and a first run via mutiny run --no-hosted (Hosted remains optional / clearly labeled)
• Extend tests/unit/test_mutiny_cli_init.py to assert key strings from the hint (or document in PR why capture is impractical)
• Existing init tests still pass: uv run pytest tests/unit/test_mutiny_cli_init.py -q
• PR description links this issue (or comment “already sufficient” only if --no-hosted + test assert are already present — verify first)

Suggested files

• packages/mutiny_cli/src/mutiny_cli/init_cmd.py
• tests/unit/test_mutiny_cli_init.py

Out of scope

• Redesigning scaffold templates, changing default Hosted behavior, or new CLI subcommands

Hints

• Today’s step 4 prints mutiny run without --no-hosted — that’s the main polish.
• Capture stdout from the init function / CLI entry the same way other CLI tests do (check neighboring tests).
• Keep the block short; do not turn it into a tutorial.

Difficulty

XS · CLI DX

Docs

• Catalog: GOOD_FIRST_ISSUES.md #21
• Sample: examples/openai_support_agent