Provision the fabric store receipt MAC key (d0_store_operation_wall PR 3a)

[gunbai-bot]

PR 3a of the d0_store_operation_wall sequence (#12458 = PR 1, #12476 = PR 2).

What. It adds a third approval-loop MAC key, the store receipt key:

• gunbc.auth.approval_store_receipt approval_store_receipt_mac_key_secret_ref, approval-store-receipt-mac-key pinned at version 1;
• its accessor row in gunbc.auth.fleet_secret_accessor_roster, which also joins the roster list;
• the third key in gunbc.auth.approval_mac_key_provision provision_approval_mac_keys. The run provisions and grants all three and reports each standing.

Why a new key. The fabric store door will admit an operator-approved write only under a receipt the broker mints over its recorded decision. An HMAC verifier can also mint. If the store's serve user read the existing capability key, it could mint operator approval links, which are bearer authority over anything the broker brokers. Its own key limits what that user can forge to store receipts. The store accepts those only for writes an approved intent (PR 2's scope frame) already states.

Operator step this PR enables. Once it merges, the operator runs the entry once:

GUNBC_GCP_ACCESS_TOKEN_FILE=<0600 file> gunbc run --source-root dag --source-root src/v2 \
  --entry dag/gunbc/auth/approval_mac_key_provision.dag --function provision_approval_mac_keys

The capability and submission keys are observed with their pinned versions and left untouched. The receipt key's container is created, version 1 is added from a digested snapshot and read back, and its accessor cell is bound. The printed digest prefix becomes the keyring pin in PR 3b.

Consumers. The provisioning entry executes on the operator's run. PR 3b adds the pin, the srv1 install, the broker's minting route (authenticated by the filer's submission MAC, never on the public status route) and the client. The key id is deliberately not declared until 3b, which is its first reader.

Witness. gcp_secret_access_witness roster count goes from 5 to 6.

🤖 Generated with Claude Code

[gunbai-bot]

The floor failure is not this diff. Two wet witnesses fail, fabric_capacity_standing_wet_witness.the_live_entry_reads_the_authority_before_judging_and_refuses_off_fleet and spark_pair_serving_apply_wet_witness.the_apply_seam_reads_the_authority_before_planning_and_refuses_off_fleet, and a re-run reproduced both. They are scheduled here only because this PR edits fleet_secret_accessor_roster, which is in their closure. They assume the floor host is off-fleet, and that premise is what #12478 ("spark wet witnesses: supply the off-fleet premise … unblocks srv1-placed floors") repairs. This PR waits on #12478 and will be re-run after it lands.

— sent from lively-dove-256

[gunbai-bot]

Addressing review 72195 in 23de3bd. I replaced count(fleet_accessor_grant_roster) == 6 with a two-way identity join at secret grain over the named rows:

• every row a consumer selects by name, including the three approval MAC keys the provisioning entry grants, is a roster member;
• every roster member is one of those rows.

A swapped or dropped row now fails even when the count is unchanged. A provisioning entry naming a row that isn't in the roster fails too.

— sent from lively-dove-256