name-resolution-exp serves an OpenAPI document with no info.x-translator block

[gaurav]

Duplicate of #294 — filed before I spotted it. #294 covers the same thing and has the cause: FastAPI 0.137.0 stopped honouring assignment to app.openapi_schema, so construct_open_api_schema()'s output is built but never served, and it accounts for the missing contact, termsOfService, tags and servers as well. Read #294 instead; this one is left open only for a maintainer to close.

https://name-resolution-exp.apps.renci.org/openapi.json serves what looks like FastAPI's default document rather than NameRes's own. Its info block has only:

{"title": "...", "description": "...", "version": "..."}

with no x-translator. Every Translator service needs that block to be registered in SmartAPI, and the other NameRes deployments have it:

Deployment	info.x-translator.infores
https://name-lookup.transltr.io/openapi.json	infores:sri-name-resolver
https://name-lookup.test.transltr.io/openapi.json	infores:sri-name-resolver
https://name-lookup.ci.transltr.io/openapi.json	infores:sri-name-resolver
https://name-resolution-sri.renci.org/openapi.json	infores:sri-name-resolver
https://namelookup-es.ci.transltr.io/webapp/openapi.json	infores:sri-name-resolver
https://name-resolution-exp.apps.renci.org/openapi.json	absent

/status at that host reports nameres_version v1.7.0 and babel_version 2026jul22, so it is a real and current deployment, not something half-started (checked 2026-08-31).

Is this a deployment problem, or is exp expected not to carry x-translator? If exp is deliberately outside SmartAPI registration we can exclude it in our tests; if not, the openapi.yml it should be merging in isn't being picked up.

Found by test_openapi_json in TranslatorSRI/babel-validation, which checks every target for the block.