Decide whether caseworkctl dev may share the bregctl dev PostgreSQL container

Found while writing the public tutorial `Review BReg changes in Casework`.

## Use Case

`caseworkctl dev --source-project` runs beside a `bregctl dev` session. It borrows that session's Registry Mint as issuer and exports its clients from the registry, but it still starts a second PostgreSQL container for Casework.

## What we hit

The Casework runtime refuses plaintext PostgreSQL unless the binary is built with the `postgres-test` feature and the runtime file sets `database.testOnlyPlaintext: true` (`crates/registry-casework/src/config.rs`, documented in `products/casework/RUNTIME-CONFIG.md`). The `bregctl dev` container speaks plaintext on loopback, so the Casework dev session cannot share it with a release build.

## Decision needed

1. Keep two containers (what ships today; the tutorial documents it).
2. Let the dev session use a loopback plaintext connection under an explicit dev-only setting that release builds accept.
3. Have `bregctl dev` provision TLS for its container so both dev sessions can share it.

Option 1 costs one extra container per reader. Option 2 touches a deployment default and needs a security review note. Option 3 is the cleanest runtime story but the largest change.

Triage: later, needs a product decision first.

Start with crates/registry-casework/src/config.rs and products/casework/RUNTIME-CONFIG.md, then review the public `Review BReg changes in Casework` tutorial and the three proposed container-sharing options. Done means a product decision is recorded and the tutorial and relevant runtime or deployment guidance reflect the selected approach.

Written by the indexing model from the issue text.