Registry serves no CORS headers, so a browser dApp on another origin cannot read its responses

[lmcorbalan]

User story / Problem statement

Currently the registry mounts no CORS middleware, so a browser dApp on another origin can send a
request but cannot read the response. canton-dappbooster hit this: its dev server is on 3012 and
the registry on 3013, so the metadata calls its config load depends on fail with an opaque
TypeError: Failed to fetch, and the transfer-factory POST triggers a preflight nothing answers.

Expected outcome

A browser dApp on a configured origin can call the registry directly and read the responses,
preflighted POST included. Which origins are allowed is deployment configuration, not a
hardcoded wildcard.

Acceptance criteria

• The registry answers Access-Control-Allow-Origin for a request from an allowed origin
• A preflight OPTIONS on the transfer-factory route is answered without reaching the OpenAPI validator
• Allowed origins come from configuration, with a documented default
• An origin that is not allowed is refused rather than silently permitted
• The README records the new configuration key

Alternatives considered

Each consumer proxies the registry behind its own origin. It works, but every consumer
reimplements it and the registry's routes end up behind a second URL shape.

Technical notes

registry/src/server.ts mounts only the request-target canonicaliser, express.json(), the
OpenAPI validators and the routers, and the package has no cors dependency.
registry/src/config.ts has no origins key. @bootnodedev/canton-wallet-service already does
this with the cors package and a WALLET_SERVICE_CORS_ORIGINS list, a shape worth matching.

Additional context

Found while implementing BootNodeDev/canton-dappbooster#172, which points its dApp at the
registry on 3013.