sp-k7s. The 0.7.0 changelog names the outcome_blob column, the GIN
jsonb_path_ops index and the `from: 3` call, but not the two things a
host operating a database has to know: that the migration runs before
the deploy, and what the index build costs on a large runs table.

V03's up/1 issues a plain `create(index(...))`, not CREATE INDEX
CONCURRENTLY, so the build takes a SHARE lock and blocks every write to
the runs table until it finishes. Whether that should change is a
migration decision and a separate issue; this change documents what
ships.

README gains "Upgrading to V03 before deploying 0.7.0" in the Ecto
adapter section: the ordering rule and why it is not symmetric
(outcome_blob is an unconditional field on the generated runs schema, so
0.7.0 against a V02 database fails every query that touches runs, not
only the fan-out write), the migration snippet, the cheap column half
against the locking index half, and the hand-rolled concurrently: true
alternative for a host with millions of rows - with the warning that a
host taking that route must not then call up(from: 3), because V03 uses
create/1 rather than create_if_not_exists.

The metadata section's V02 clause said the column ships with no index
and that a GIN index is yours to add. V03 shipped exactly that index, so
the clause is narrowed to what is still the host's call rather than left
contradicting the section above it.

CHANGELOG.md's 0.7.0 section - untagged, and named by the campaign
dispatch as editable - gains a pointer to the new README section.

Also noted: sp-461 is the measurement issue if the "how large before it
hurts" question needs a number.

Docs-only, so no gate applies (CLAUDE.md: a change touching no Elixir
code has no gate to run, and gate.build_paths covers neither file).
`mix docs` builds both extras clean. No changelog fragment: documentation
is on changelog.d/README.md's "do not write a fragment" list.