Sync narrative examples with the schema, and make internal component keys consistent (#311)

[taleodor]

Summary

Cleanups after #323, on main as of #320:

1. Documentation sync — the narrative documents carried examples and field descriptions that no longer matched spec/openapi.yaml. Every JSON block in them now validates against the schema it claims to illustrate (13 blocks, 0 failures — was 9 failing).
2. Make internal component names consistently kebab-case in openapi.yaml #311, internal component keys — kebab-case schema keys, the FedRAMP enum value, and a recorded exception for the two security scheme names.

Five commits, each self-contained; the #311 commit can be dropped if TC54 wants that discussion separate.

#311 — internal component keys

Change	Scope
productRelease → product-release	schema key, 2 $refs, 2 prose mentions
release → component-release	schema key, 2 $refs, 1 prose mention
tea-server-info → server-info	schema key, 1 $ref
FedRAMP → FEDRAMP	compliance-document-type enum
bearerAuth / basicAuth	unchanged, with a comment recording why

• release → component-release is not a pure refactor: the generated model becomes ComponentRelease in every language. Worth doing anyway — the schema describes itself as "A TEA Component Release", and release next to component-release-with-collection read as two different things.
• tea-server-info → server-info removes the last Tea prefix on a schema key, the same prefix Harmonise operationIds in openapi.yaml #312 removes from operationIds. Side benefit: generating a server with modelNamePrefix=Tea currently produces TeaTeaServerInfo; it now produces TeaServerInfo.
• FedRAMP → FEDRAMP is a wire value, not cosmetics: OpenAPI schema consistency fixes #323 made idValue a shall for COMPLIANCE_DOCUMENT, so it lands before the freeze or not at all. Every other entry in the enum is already screaming-snake, and FedRAMP appears nowhere in CycloneDX 1.6 / ECMA-424 and only inside prose descriptions in 2.0-dev, so there is no sibling-spec value to stay consistent with.
• bearerAuth / basicAuth kept: generated clients surface these names as the identifiers a caller configures credentials with (authentications.put("bearerAuth", …) in Java, auth['bearerAuth'] in Python). A comment above securitySchemes records the exception.

Documentation sync

tea-component/tea-release.md

• Add the required component to every release example.
• Replace the three blocks introduced as "reused from the OpenAPI schema" with the schema's actual examples — Log4j Core 2.24.3, Tomcat 11.0.7, and the 11.0.0-M26 pre-release. They previously showed Tomcat 11.0.6 and a Tomcat 10.1.40 release under da89e38e-…, the uuid the schema uses for Log4j Core.
• distributionId values are UUIDs, matching the schema. Distributions are named in prose by what they are rather than by their identifier, and the introduction no longer asks producers to define a taxonomy of distributionId values: a UUID is unique within the TEA server by construction, and what a distribution represents is carried by its description.
• SHA_256 / SHA_512 → SHA-256 / SHA-512, the checksum-type spelling.
• Required-fields list gains component; distributionOd typo; a release's identifiers are the release's, not the component's; the Windows x64 distribution pointed its signatureUrl at the non-Windows archive.

tea-collection/tea-collection.md

• The collection example gains the artifact createdDate and version the schema requires, drops the MD5 checksum (removed from the enum) in favour of the SHA-256 the schema publishes for the same artifact, and uses the uuid of the release it belongs to with dates ordered after the artifact revisions it contains.
• distributionType → distributionIds; artifact version is a revision number rather than "an integer with default value 1" (OpenAPI schema consistency fixes #323 removed that default from a required property).

tea-product/tea-product-release.md

• product and the TEI value match the schema's product-release example; the previous TEI (tei:vendor:product@2.24.3) was not in TEI syntax.

README.md, tea-product/tea-product.md

• A TEI resolves to one or more Product Releases, normally one — as discovery/readme.md and the /discovery response have said since docs: clarify discovery cardinality, response shape, and PURL (#279) #304.

Both spec/openapi.yaml and the documentation

• The Tomcat Windows distribution is Apache's Windows Service Installer, an NSIS self-extracting .exe (its own url ends in .exe), not an MSI.

Verification

• swagger-parser: valid; all 43 embedded examples validate against their schemas.
• All 13 JSON blocks in the narrative documents validate against the schema each illustrates (ajv, dereferenced).
• openapi-generator v7.24.0 (the pinned CI version) generates go, python, typescript and java-webclient without errors. Model-name effect of the renames: Release → ComponentRelease, TeaServerInfo → ServerInfo, ProductRelease unchanged.