Extend read_only config into all/prod/off modes

[aprimakina]

read_only was a bool: writes were refused either everywhere or nowhere. It now takes three modes, so an agent can be let loose on development services while production stays protected:

• all: every service (equivalent to the old true)
• prod: only services tagged PROD
• off: nothing (equivalent to the old false, and still the default)

The booleans keep working - read_only: true in a config file, or TIGER_READ_ONLY=true, still mean all. The default stays off; flipping it to prod is a separate decision, since it would change behavior for production services - notably tiger db connect, which would start opening read-only sessions.

Because prod protects only services tagged PROD, every gate needs its target's environment tag. common.CheckReadOnly(cfg, tag) is the verdict, and CheckReadOnlyByServiceID fetches the service when only its ID is known - one extra API call, and only under prod. Both require a tag, so a gate cannot silently skip prod mode.

Notes on the individual surfaces:

• MCP registration cannot express prod, so the write tools stay registered (they still work on DEV services) and refuse per call instead. The server instructions gained a prod variant so a refusal does not look like a bug, and ServiceDetail now reports each service's environment tag so the model can check before offering to modify one.
• Database sessions reach the same verdict as the control-plane gate: a mode that refuses writes to a service also opens its connections read-only. That covers the connection strings embedded in service get/list output, not just the db commands.
• A replica set is judged on its own environment tag rather than its primary's, on both planes, matching how the API tags replica sets individually.
• db create role is gated too, and the db connect password-recovery menu no longer offers to rotate the password of a protected service.

First-login prompt

read_only defaults to off, so the protection above only reaches users who go looking for it. Flipping the default would change behaviour for every existing user — notably tiger db connect, which would start opening read-only sessions against PROD services, with Postgres reporting the refusal so nothing points at the setting.

A first interactive tiger auth login now offers it instead:

Protect services tagged PROD from writes? [Y/n]:

• Triggered only when no credentials existed beforehand, so existing users are never asked and no default changes. The answer is written to the config file, so config show reflects a choice rather than a version-dependent default.
• Both answers are recorded, so it asks exactly once. Declining stores read_only: off rather than leaving the key absent — absence can't record a negative answer, so a logout and second login would otherwise ask again. The guard tests key presence rather than the resolved value, since off is also the default.
• Skipped when stdin isn't a terminal, so scripted and CI logins neither block nor change behaviour. Unlike the CLI's other TTY gates it skips silently rather than erroring, since nothing is being refused.