Land feature 57's controller work on its release branch

The controller plans config, templates and moved providers' provisions,
hands bus accounts to the vault and judges the new manifest words, on the
feature's SDK and node-engine validator (feature 57, config and provisioning).

internal/inventory/migrations/0099-the-secrets-move-into-the-vault.sql

@@ -0,0 +1,22 @@
+-- The move of the controller's secrets into the vault (novox/hq ADR 0349 clause 7; design 57's V3, issue 676).
+--
+-- The controller cannot open a value it holds, so each machine's node-engine hands in what was sealed to it, and a
+-- machine asleep when the move starts is moved when it is next heard from. These two tables are what lets the
+-- controller tell, then and later, what has moved: that the move was started, by whom, and whether the record of
+-- asks was copied; and each row the vault took, under the vault's name for it, with the machine whose engine handed
+-- it in, the vault's generation, and a digest of the sealed text the row held then — so a row the controller
+-- changed after it moved is said, never moved over the vault's value. No value and no sealed value is kept here.
+create table secret_move (
+    one           boolean     primary key default true check (one),
+    started_at    timestamptz not null default now(),
+    started_by    text        not null,
+    asks_moved_at timestamptz
+);
+
+create table secret_moved (
+    secret        text        primary key,
+    node          uuid        not null references node(id) on delete cascade,
+    generation    integer     not null check (generation > 0),
+    sealed_digest text        not null,
+    moved_at      timestamptz not null default now()
+);

internal/inventory/migrations/0100-a-send-keeps-the-provisioners-plans.sql

@@ -0,0 +1,10 @@
+-- What a machine was last sent of the provisioner's plans (novox/hq ADR 0349 §4, design 57 P6, issue 672).
+--
+-- A module marked moved is handed to the provisioner on a machine whose node-engine takes a filled file on the
+-- client's word alone: its declaration names the files the client fills, and the client fills them from the
+-- module's plan — its templates archive by digest, each file's path and template, and the placement values its
+-- templates name. The plans are composed with the declaration and kept with its send, by module, so the
+-- assignments mirror carries the plan of the build that machine was sent (inventory.Provisioning) and a walk waits
+-- for the client's report on that build's templates. Null for a machine sent nothing handed. No secret: placement
+-- is not one.
+alter table node add column sent_provisioning jsonb;

internal/inventory/migrations/0101-the-cores-credentials-the-vault-sealed.sql

@@ -0,0 +1,18 @@
+-- The core's own credentials as the vault sealed them to their machine (novox/hq ADR 0349 §16, issue 755).
+--
+-- The bus's and the provisioner's credentials travel in their machine's declaration sealed by the vault to that
+-- machine, which the controller carries and cannot open. The vault seals each answer afresh, so the box the
+-- controller last got is kept here and carried again while the vault's generation and the machine's key are the
+-- same: a declaration that changed with every answer would be sent for ever. It is also what a send carries when
+-- the vault does not answer, so the machine keeps the file it has. Kept as text, byte for byte as it was carried
+-- (jsonb would reorder its keys, and the declaration with them). Sealed to the machine's key: no value.
+create table core_box (
+    node       uuid        not null references node(id) on delete cascade,
+    module     text        not null,
+    name       text        not null,
+    generation integer     not null check (generation > 0),
+    sealed_to  text        not null,
+    box        text        not null,
+    got_at     timestamptz not null default now(),
+    primary key (node, module, name)
+);

internal/inventory/migrations/0102-the-settings-layers-move-into-config.sql

@@ -0,0 +1,15 @@
+-- The settings layers move into mesh-config (novox/hq ADR 0348 §9, design 57 K5, issue 664).
+--
+-- Every config value a settings layer holds is set in mesh-config by the move of config (`move-config`), one of the
+-- moves of data a release runs once after its delivery; the layers it moved keep their rows, emptied, so the
+-- placement kept beside each stays where it is, and each is kept whole in the history first. This row is the
+-- switch: while it is absent the controller composes from the layers as before; once the move has run and read
+-- every value back through mesh-config, it is written, and the controller reads a module in the config form from
+-- mesh-config_resolved where it read its layers (ADR 0349 clause 17's old way, an exception to ADR 0348 §9 that
+-- design 57's R1 removes). One row at most; never written by a migration, so a delivery alone changes nothing.
+create table config_move (
+    only_one boolean     primary key default true check (only_one),
+    moved_at timestamptz not null default now(),
+    moved_by text,
+    why      text        not null
+);