docs: OpenAI verification pack + hosted-demo-browser recommendation

[dzianisv]

Follow-up to #124. Two directory-submission prerequisites, assessed against freshly fetched official docs and measured against production today.

TASK A — domain + business verification

Domain verification is a .well-known HTTPS file only — there is no DNS TXT record. Worth stating plainly: our apex already carries Google, Microsoft and Brevo TXT verifications, so "add a TXT record" is the natural but wrong assumption.

The DNS/hosting half is done and live — VibeTechnologies/platform#69:

$ curl -s https://relay.api.vibebrowser.app/.well-known/openai-apps-challenge
{"error":"Domain verification token not configured"}     # new handler, deployed

$ curl -s https://relay.api.vibebrowser.app/.well-known/nope
Not found                                                # generic 404 — proves the above is ours

Returns 200 text/plain with the bare token once OPENAI_APPS_CHALLENGE_TOKEN is set; 404 while unset, deliberately never an empty 200 (an empty body reads as a valid-but-wrong token and could burn a verification attempt).

Why the relay host, not the apex: the apex 307s to www.vibebrowser.app, and www is a sibling of the MCP host, not a parent — so it is ineligible as a challenge base. The relay host is redirect-free and is the portal's default.

worklog/openai-verification-pack.md (new) holds the business-verification pack: entity data (UBI, EIN, D-U-N-S, registered agent), public URLs all measured 200 today, support contact, a paste-ready product description, and the MCP server details — including why we must submit Universal rather than Template.

§7 — corrections to #124

• The OAuth gap is closed. platform#67/fix: ship startup fallback and set_remote UUID support #68 shipped; /mcp now returns 401 with a correct WWW-Authenticate: Bearer resource_metadata=... and both OAuth well-knowns return 200. We have a universal URL, which removes the template-URL disqualifier. §4 is now a design record, not a TODO.
• Correction — annotations are NOT done on the path that matters. vibe-mcp#125 annotated the npm stdio package. The relay proxies tools/list straight from the extension, whose McpServerToolDefinition has no title and no hints, so the endpoint both directories actually scan still advertises zero annotations. Cheapest fix is to enrich in the relay (a deploy) rather than the extension (a Chrome Web Store release).

TASK B — demo browser: recommendation

Anthropic does not require working tools to be listed. Submissions are auto-scanned and listed as community connectors by default; a functional per-tool test happens only on an escalation we cannot request. Recommend building nothing for Anthropic.

OpenAI does require them, in three independent places — most sharply, Scan Tools cannot even populate the draft, because our relay errors -32002 on tools/list with no extension connected.

Recommend AGAINST a persistent, cluster-hosted browser. Our toolset includes evaluate_script (arbitrary JS) and web_fetch (arbitrary URL). A browser inside the cluster that holds vibe-secrets is a plausible metadata-service (169.254.169.254) SSRF path to production secrets. Free in cash, not worth the risk — and that risk is created purely by the "keep it free, reuse the existing cluster" choice.

For OpenAI only, build the narrow version: an ephemeral, allowlisted, credential-free session reusing the existing vibe/tests/cua/ Xvfb+Chrome harness, exploiting the fact that the extension dials outbound so no inbound port is needed. A 6h job cap gives the time box for free.

Cost, honestly: no new paid services and no new cloud spend either way — but "free" overstates it. VibeWebAgent is private, so it consumes ~360 metered Actions minutes per 6h window (~1,000–2,000 for a realistic review) from the existing allowance.

Sequenced last, behind the annotations fix, so we never open a submission that is already guaranteed to be rejected — only one version may be in review at a time and the queue has no published SLA.

Docs-only; no code paths touched.