fix(spec): validate top-level OpenAPI versions

[saltbo]

What changed

• require generic JSON/YAML candidates to declare a top-level OpenAPI 3.x version before selecting the built-in loader
• keep official OpenAPI media types and Swagger 2 detection behavior intact
• preserve malformed-document errors when a JSON document declares its version before later invalid content
• add regression coverage for service metadata containing an OpenAPI document URL and nested openapi fields

Why

Spec discovery probes the API root, advertised service-desc links, and well-known OpenAPI paths concurrently. A service root representation such as:

{"name":"Example API","openapi":"https://api.example.com/openapi.json"}

was accepted as an OpenAPI document because detection searched for the word openapi anywhere in a generic JSON/YAML body. If that root probe completed first, Restish cached an empty operation set instead of using the advertised OpenAPI document.

The OpenAPI Object requires openapi to be a top-level specification version. Validating that boundary rejects service metadata while leaving the existing discovery probes to select the real document.

Impact

Generated commands are now stable for APIs whose root metadata publishes an OpenAPI URL under an openapi field. Existing valid OpenAPI 3.x documents, including documents with a late top-level version field, continue to load.

Verification

• go test ./internal/spec -count=1
• go test ./internal/cli -count=1
• go test -race ./internal/spec ./internal/cli
• go vet ./internal/spec ./internal/cli
• go test ./... passes all packages except the pre-existing local cmd/restish-pkcs11 build failure caused by unavailable PKCS#11/cgo symbols in github.com/ThalesIgnite/crypto11