docs(registry): correct what a refused CORS origin leaves behind

[lmcorbalan]

Summary

No related issue. PR #173's merge took the branch head from before its last review round, so these five commits are on the branch and not on main. They are that round's three documentation fixes plus the test that pins one of them.

Changes

• README, RUNBOOK and index.ts no longer claim the service logs no requests: the error handler logs every 5xx with its method and path, and what actually holds is that no log line names the origin.
• README states the rule by method rather than counting GET routes, which undercounted (five exist, not three).
• config.ts records why a permissive CORS_ORIGINS default is bounded: the service authenticates no client, so the list decides which pages a browser hands a response to, never who may ask for one.

Acceptance criteria

• The three findings from PR feat(registry): serve CORS headers for configured browser origins #173's fourth review round are fixed, with no behaviour change: every edit is prose except the added test.

Test plan

Automated tests

246 registry unit tests in 11 files (was 245); 80 Daml scenarios in 12 modules; 18 e2e in 4 files against a live participant on Canton 3.5.12. Lint, both typechecks, check:deps and smoke:registry all clean.

Manual verification

The new test earns its place by the one mutation that separates it from errors.test.ts: adding origin: req.headers.origin to the 5xx log line reds only the new test, while dropping the log line or its method and path reds pre-existing tests too. A 24-mutation battery over the CORS layer and parseOrigins reds every guard discriminatingly and found no correctness bug in src/.

Breaking changes

None.

Checklist

• Self-reviewed my own diff
• Tests added or updated
• Docs updated (if applicable)
• No unrelated changes bundled in

Screenshots

None.