feat: update default Aztec version to v5.0.0-rc.1

[critesjosh]

What

Bumps DEFAULT_AZTEC_VERSION from v4.3.0 → v5.0.0-rc.1, the version testnet is currently running.

Version-tag verification

Checked git ls-remote against every repo the version tag actually applies to — v5.0.0-rc.1 exists on all of them:

Repo	v5.0.0-rc.1	Notes
aztec-packages	✅	also drives the versioned-docs sparse path
aztec-examples	✅
aztec-starter	✅
demo-wallet	✅	exact match (matchLatestIncrementalTag, exact tag present)
gregoswap	n/a	skipVersionTag: true — unaffected
noir / noir-examples	n/a	non-Aztec repos pinned to master — unaffected

The aztec-packages sparse-path override resolves docs/developer_versioned_docs/version-{version} → version-v5.0.0-rc.1, which exists on the next branch (alongside version-v4.3.1). Note the old v4.3.0 default pointed at version-v4.3.0, a directory that no longer exists on next — so this is also more correct than before.

Changes

• src/repos/config.ts — DEFAULT_AZTEC_VERSION (functional) + JSDoc example
• src/index.ts — aztec_sync_repos tool description example
• README.md — version examples (×4)

Notes

• This is a release candidate, not a final tag — when v5.0.0 ships, the default will want another bump.
• Build clean; all 306 tests pass. (Version-check test fixtures mock DEFAULT_AZTEC_VERSION locally, so they're unaffected.)

🤖 Generated with Claude Code

[critesjosh]

Codex review (gpt-5.5, high reasoning effort)

Verdict: REQUEST CHANGES → addressed below.

• Low (fixed): test.mjs:26 still hardcoded v4.3.0. My initial grep didn't cover .mjs. Fixed in 485f70e.
• Medium (won't-fix in this PR — pre-existing & intentional): normalizeVersion() strips the pre-release suffix, so v5.0.0-rc.1 normalizes to 5.0.0 and the version gate would treat it as equal to a final v5.0.0 corpus. This is deliberate, documented behavior (src/utils/version-check.ts design comment + the test asserting v4.2.0-aztecnr-rc.2 ≡ v4.2.0). It's lower-risk today since testnet and the corpus are both on rc.1, so there's no live mismatch — but it becomes relevant when final v5.0.0 ships (the same moment the default needs another bump). Flagging rather than silently changing gate semantics; happy to open a follow-up if we want rc-vs-final to register as a mismatch.
• No issue: matchLatestIncrementalTag handles v5.0.0-rc.1-N style suffixes correctly. sparsePathOverrides substitutes to version-v5.0.0-rc.1, which I separately verified exists on the next branch via the GitHub API.

Codex couldn't reach GitHub (sandboxed) or run Vitest (read-only fs); upstream tag existence was verified separately, and all 306 tests pass locally after the fix.