docs(destinations): add passthrough recipes for postgres/s3/console

Per ADR-0003, postgres/s3/console are pure Vector-sink wrappers with no
DC-specific logic, so anyone using the blessed form today can migrate to
raw Vector `custom_config_files` passthrough now, ahead of #471/#472's
code removal. Each recipe reproduces exactly what dc_bridge itself
renders for the blessed form and was verified end-to-end against a live
Vector 0.57.0 binary, real PostgreSQL and RustFS containers, and a
synthetic fluent-forward event (ingested row/object/console line
confirmed, not just written by inspection).

Also documents a real gap found while verifying: Vector 0.57.0 gates its
own ${VAR} config interpolation behind
VECTOR_DANGEROUSLY_ALLOW_ENV_VAR_INTERPOLATION, which dc_bridge never
sets for the vendored Vector process it execs, so a passthrough
snippet's ${VAR} silently stays literal unless that env var is set on
the Bridge process itself.

Adds doc/src/dc/migration.md as the landing page for this and future
blessed-to-passthrough moves, linked from destinations.md and
SUMMARY.md.

Closes #470

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011LXd466a9kszZJxUR51ey7
Signed-off-by: David Bensoussan <d.bensoussan@proton.me>

Author: Minipada

doc/src/SUMMARY.md

@@ -77,6 +77,7 @@
 - [Destinations](./dc/destinations.md)
 - [KPI views](./dc/kpi_views.md)
 - [Configuration examples](./dc/configuration_examples.md)
+- [Migration](./dc/migration.md)
 - [Infrastructure setup](./dc/infrastructure_setup.md)
   - [Adminer](./dc/infrastructure_setup/adminer.md)
   - [Elasticsearch](./dc/infrastructure_setup/elasticsearch.md)

doc/src/dc/destinations.md

@@ -298,6 +298,101 @@ against a simulated robot. [MCAP recording](./demos/mcap_recording.md)
 passthrough consumed by a standalone process instead of a Vector-native sink — the shape
 to follow for any store Vector has no sink for at all.
 
+### Recipes: `postgres`, `s3`, `console` via passthrough
+
+Per ADR-0003, `postgres`, `s3` and `console` are pure Vector-sink wrappers with no
+DC-specific logic layered on top — Vector's own `vector validate` already gives clear,
+field-level errors for these three sinks, so passthrough loses nothing on the validation
+front for this subset. Anyone using the blessed form today can move to passthrough now,
+before the blessed code path for these three types is removed
+([#471](https://github.com/minipada/ros2_data_collection/issues/471),
+[#472](https://github.com/minipada/ros2_data_collection/issues/472)). Each recipe below
+reproduces exactly what `dc_bridge` itself renders for the equivalent blessed
+configuration in [Configuration contract](#configuration-contract) above — confirmed by
+running Vector 0.57.0 against a live PostgreSQL and RustFS instance, not just written by
+inspection.
+
+As with any passthrough, at least one blessed Destination is still needed to create the
+`dc.<tag>` route the snippet consumes — `console` is the cheapest (see
+[above](#passthrough-custom_config_files)). If you're migrating the `console` Destination
+itself, keep a `file` Destination (or another cheap blessed type) as the route anchor
+instead.
+
+**`postgres`** — the blessed form's `host`/`port`/`user`/`password`/`database` collapse
+into a single connection-string `endpoint`; `table` is unchanged:
+
+```toml
+# ~/.dc/postgres_sink.toml — passthrough equivalent of the blessed `pgsql` Destination
+[sinks.pgsql]
+type = "postgres"
+inputs = ["dc.dc.measurement.uptime"]   # the public dc.<tag> route
+endpoint = "postgres://dc:${DC_PG_PASSWORD}@127.0.0.1:5432/dc"  # user:password@host:port/database
+table = "dc"
+
+[sinks.pgsql.buffer]
+type = "disk"
+max_size = 268435488   # Vector's disk-buffer minimum; a passthrough sink gets none by default
+```
+
+If `user` or `password` contain characters reserved in a URI (`:`, `@`, `/`, `%`),
+percent-encode them yourself — `dc_bridge` does this automatically when rendering the
+blessed form, but a passthrough `endpoint` is handed to Vector verbatim.
+
+**`s3`** — Vector's own sink id is `aws_s3`, not `s3`; credentials move under
+`[sinks.<name>.auth]` and `batch_timeout_secs` becomes `[sinks.<name>.batch] timeout_secs`:
+
+```toml
+# ~/.dc/s3_sink.toml — passthrough equivalent of the blessed `rustfs` Destination
+[sinks.rustfs]
+type = "aws_s3"                          # Vector's sink id — not "s3"
+inputs = ["dc.dc.measurement.uptime"]
+bucket = "dc-records"
+endpoint = "http://127.0.0.1:9000"       # omit for AWS S3
+region = "us-east-1"
+key_prefix = "robot1/"
+force_path_style = true                  # path-style addressing for self-hosted stores
+
+[sinks.rustfs.auth]
+access_key_id = "rustfsadmin"
+secret_access_key = "${DC_S3_SECRET}"
+
+[sinks.rustfs.batch]
+timeout_secs = 60                        # object write interval; Vector default 300
+
+[sinks.rustfs.buffer]
+type = "disk"
+max_size = 268435488
+
+[sinks.rustfs.encoding]
+codec = "json"
+```
+
+**`console`** — has no required fields either way, so this recipe mostly matters for
+consistency with the other two once the blessed path is gone:
+
+```toml
+# ~/.dc/console_sink.toml — passthrough equivalent of the blessed `console` Destination
+[sinks.debug_console]
+type = "console"
+inputs = ["dc.dc.measurement.uptime"]
+target = "stdout"                        # or "stderr"
+
+[sinks.debug_console.encoding]
+codec = "json"
+```
+
+```admonish warning
+Unlike the blessed form's `password`/`secret_access_key` (expanded by `dc_bridge` itself
+before it ever writes a config file), the `${VAR}` references above are Vector's *own*
+interpolation and are otherwise off in the vendored Vector 0.57.0 binary `dc_bridge`
+spawns — a snippet's `${VAR}` is left as a literal string, silently sent as the password
+verbatim (or rejected outright, if it contains a reserved URI character like the braces
+here). Set `VECTOR_DANGEROUSLY_ALLOW_ENV_VAR_INTERPOLATION=true` in the environment that
+launches the Bridge process itself (the vendored Vector inherits it) to make Vector honor
+`${VAR}` inside passthrough snippet content. Without it, put the literal secret in the
+file and rely on filesystem permissions instead.
+```
+
 ## File uploads: `receives: files` (the Uploader, [ADR-0005](./adr/0005-file-uploads-are-bridge-responsibility.md), [ADR-0014](./adr/0014-uploader-runs-as-its-own-process.md))
 
 A Destination with `receives: files` (only `type: s3` qualifies) is served by the

doc/src/dc/migration.md

@@ -0,0 +1,29 @@
+# Migration
+
+This page tracks in-progress moves between configuration shapes DC itself is making —
+distinct from [Configuration examples](./configuration_examples.md), which teaches the
+current shape from scratch.
+
+## Blessed `postgres`/`s3`/`console` → passthrough
+
+[ADR-0003](./adr/0003-blessed-destinations-plus-passthrough.md) blesses `postgres`, `s3`,
+`file`, `console` and `vector` with a ROS-param form rendered into Vector config by
+`dc_bridge`. An audit of that blessed set found `postgres`, `s3` and `console` carry no
+DC-specific logic — they are pure Vector-sink wrappers, and Vector's own `vector validate`
+already gives clear, field-level errors for them. `dc_bridge`'s blessed code path for
+these three types is being removed
+([#472](https://github.com/minipada/ros2_data_collection/issues/472)), once every
+in-repo demo, deploy param file and doc using them is moved to passthrough
+([#471](https://github.com/minipada/ros2_data_collection/issues/471)). `file` and
+`vector` are unaffected — `file` drives the Uploader
+([ADR-0005](./adr/0005-file-uploads-are-bridge-responsibility.md)) and `vector` is
+reserved for the split-deployment/fleet work in
+[#440](https://github.com/minipada/ros2_data_collection/issues/440); neither is a plain
+sink wrapper.
+
+**You do not need to wait for #471/#472.** Working passthrough recipes for all three
+types — reproducing exactly what `dc_bridge` renders for the blessed form today, verified
+against a live Vector instance — are in
+[Destinations: Recipes](./destinations.md#recipes-postgres-s3-console-via-passthrough).
+Point `custom_config_files` at one of them and drop the equivalent blessed Destination
+block; nothing else about your Measurements or routing changes.