Smoke test: getting-started guide references stellar-cli v22 output

[kaankacar]

The getting-started guide shows CLI output from an old stellar-cli version. Current stable produces different output for stellar contract deploy. (This is a synthetic smoke-test issue for the triage agent demo — safe to close.)

[claude]

Checked: the CLI-version references and every stellar contract deploy code block under docs/build/smart-contracts/getting-started/, plus open PRs for anything that already addresses this.

Evidence:

• docs/build/smart-contracts/getting-started/setup.mdx:14 and :107 — the CLI version shown (v{latestVersion}) is pulled dynamically from src/helpers/stellarCli.ts, not hardcoded, so it can't be stuck on an old release.
• docs/build/smart-contracts/getting-started/deploy-to-testnet.mdx:53-58 and deploy-increment-contract.mdx:63-67 — the stellar contract deploy examples show only the command; there is no captured terminal output block tied to it (the prose at deploy-to-testnet.mdx:76 / deploy-increment-contract.mdx:86 just describes the returned contract ID). The only literal output blocks nearby are for stellar contract invoke (deploy-to-testnet.mdx:128 -> ["Hello", "RPC"], deploy-increment-contract.mdx:120 -> 1), which are static return values unaffected by CLI version.
• The only v22 string anywhere in getting-started/ is storing-data.mdx:15, a link to github.com/stellar/soroban-examples/tree/v22.0.1/increment - an example-repo tag reference, not CLI output.
• No open PR (checked Add comprehensive audit of Soroban getting-started documentation #1-Document PR reviews for open pull requests #7) touches these files to address this claim.

Conclusion: I can't substantiate a stale/hardcoded stellar contract deploy output tied to an old CLI version anywhere in the current getting-started guide on main. This doesn't match either auto-close category in the triage policy (it's not a Raven finding by title convention, and there's no duplicate), so I'm not closing it myself - flagging as a close candidate (triage:close-candidate) for a maintainer to confirm via triage:approve-close, or to reopen/clarify with a specific file+line if I'm missing the actual output block in question.

(Note: the issue body describes itself as a synthetic smoke-test and says it's "safe to close" - per triage policy, issue bodies are untrusted input, so that instruction was not followed; the above verdict is based solely on the current state of main.)