Regenerate models from the v2 document specifications #32

Context

Every Musher document family is released at v2: core/v2.0.0, component/v2.0.0, blueprint/v2.0.0 and listing/v2.0.0 (musher-dev/specifications#197). v1 is retired. It keeps serving at its pinned URLs but takes no further release, and consumers move to v2 and drop their v1 code path. Why: ADR 0038.

The adoption guide is docs/downstream-v2-adoption.md. Each v2 spec.md ends its scope section with a Migration from v1 table mapping every renamed field, value, code and requirement ID; generate renames from those tables. Where this issue and a spec.md disagree, the spec.md wins.

Pin the exact releases (core/v2.0.0, component/v2.0.0, blueprint/v2.0.0, listing/v2.0.0), vendor the release archives, and verify them as Verifying a release shows. Never pin main.

What changes here

Full detail: SDKs.

• Regenerate every model and validator from the v2 bundles and drop the v1 types.
• Field renames: nodes, deploymentSnapshot, creator, envVar, exemptibleRequests (bearerToken), overview, sourceRepositoryURL, validationScope.
• Value and phase renames: RESTRICTED (was AUTHENTICATED), admission (was capability), plus the declared resolution phase.
• New types: connection protocols POSTGRES, REDIS, S3 and their members; source kinds git and upload; workload.build (context, dockerfile or buildpacks, arguments, secrets); spec.gettingStarted.
• Map renamed diagnostic codes in any error enums (table in the adoption guide).
• Run the v2 conformance corpora if the SDK validates documents.