model_specs: correct voxcpm1 defaults to the engine's own

[CryptVenture]

Split out of #372 as requested. This PR is the VoxCPM1 defaults only; the description-only fixes, the strict contract fixes, the ASR/aligner/codec declarations and the MiniMax declarations are separate PRs.

The problem

The four defaults the spec published for VoxCPM1 were not the values the engine uses. A client that populated its form from the spec — the WebUI does — sent a slower and shorter configuration than the model's own defaults, and every one of those requests was legal, so nothing surfaced the mismatch.

Option	Spec said	Engine uses
num_inference_steps	50	10
max_tokens	1024	4096
min_tokens	0	2
retry_badcase_max_times	2	3

The engine values are the initialisers of VoxCPM1GenerationOptions in include/engine/community_models/voxcpm1/types.h:13-19, which the session applies whenever the request omits the option.

The change

The spec now publishes those four numbers. Types, bounds and required flags are untouched, so every request accepted before is still accepted; only the value a spec-driven client sends by default changes, and it changes to the one the engine would have used anyway.

Validation

python3 tools/check_loader_catalog_sync.py
# ok: runtime loaders, model_specs, and model_manager_v2 are in sync

audiocpp_model_manager list --repository-root .        # exit 0

Read against types.h, not run against a package: no VoxCPM1 weights are installed on this machine.

Scope

One spec file, four values. The generated WebUI bundle is deliberately not included — catalog.ts inlines model_specs/*.json at frontend build time and the bundle is not byte-reproducible, so regenerating it in every PR of this split would make the PRs conflict with each other. Happy to send one bundle-regeneration PR once the series lands.

[CryptVenture]

Closing for now to stay inside the 3-concurrent-PR policy (see the discussion on #422). Nothing is wrong with the change and CI is green on it; I will reopen it as review slots free.