Service registry

It carries no account_var, and that is deliberate rather than an omission. The other services hold an IAM account because they act as themselves: they open a database connection, and a validator or a permission check resolves who they are. This one acts for the browser. It reaches the bus over the same mutual-TLS client certificate every service presents, and the identity a service acts on is the caller's, which travels with the request. Giving it an account would give it an identity that nothing reads and nothing can check.

Answers put, get, delete and list on the storage.v1.objects.* subjects, over the same storage root the HTTP routes are given, so a caller reaches one set of objects either way. It holds no tables: the database gives it the request context the shared runner hands to a handler, and nothing else.

description: stays a few words because three templates append "; domain service" to it for a SQL comment and a service-account label. A paragraph here reads back as "… and nothing else. domain service".

Answers the approval request and notification operations. It owns the inbox tables, and reads IAM to resolve a permission audience into the accounts that hold the permission.

It carries no account_var: it reaches nothing but the bus and the public publishers, and the market data service maps and stores what it sends. Each --source is a feed of the official rates catalogue, projects/ores.sql/populate/marketdata/marketdata_official_catalogue_populate.sql, or of the overnight rates catalogue, projects/ores.sql/populate/marketdata/marketdata_overnight_rates_catalogue_populate.sql, named with the adapter that reads it.