## 2026-09-16T15:12:32Z Part C.2 — the PBS re-issue on tester-1's REAL state, now that the grant exists
## WHY THE RE-ISSUE BUTTON IS NOT ON THE PAGE — read from source, not guessed:
##   `config_form_body.html:182` renders the „Re-issue PBS credentials" button inside
##   `{{if .PBSDR.Provisioned}}`. tester-1 currently has NO host (the drill box was torn down on
##   2026-09-16), so there is no provisioned DR descriptor and the control is correctly hidden.
##   The hub said the same thing in its own log at 17:05:09:
##     „pbsdr: DR tier ON for tester-1, no host enrolled yet — the descriptor applies once the
##      cascade is ready (host -> WG peer -> apply)".
## CONSEQUENCE: Part C.2 cannot be walked against tester-1 today, and that is the product behaving
##   correctly rather than a blocked step. The grant is proven end-to-end by the FRESH BOX in Part E:
##   its WG registration must provision `felhom-pbs` with no hand — which is exactly the path that
##   failed on 2026-09-16 with „missing Datastore.Modify". R-534 and R-511 stay open until that run.
## 2026-09-16T17:25:34Z PART C.2 — pressing „Re-issue PBS credentials" on the FRESH box (the hub itself asked for it)
  submitting the customer form to the re-issue action, fields: _csrf, cf_api_token, cf_tunnel_token, customer_id, customer_name, domain, dr_tier, email, git_token, git_username, offsite_box_type, offsite_enabled, offsite_quota_gb, offsite_type, pbsdr_storage_id
  POST pbsdr-reissue -> http=200
  hub log right after:
   2026/09/16 19:25:36 [INFO] tenantsync: reissue ok for tester-1 (ns=tester-1, token_id=felhom@pbs!tester-1; secret withheld from logs)
   2026/09/16 19:25:36 [INFO] pbsdr ADOPTED for tester-1 (host tester-1-33b6a9, ns tester-1, token_id felhom@pbs!tester-1, gen 2; fresh consume-once secret stored, withheld from logs)
   2026/09/16 19:25:38 [INFO] host-report from tester-1-33b6a9 (1 guests, 2 storage targets, 1 backups, 0 restore-tests, 0 pbs-snapshots, 11186 bytes)
   2026/09/16 19:25:38 [INFO] DR-recipe host-half stored for customer tester-1 (host tester-1-33b6a9, v1)
   2026/09/16 19:25:38 [INFO] pbs token secret consumed by host tester-1-33b6a9 (single-use; value withheld from logs)
## R-511 REPRODUCED ON THE FRESH BOX, from the hub's own log (2026-09-16 18:01:19 CEST):
##   „[ERROR] pbsdr auto-provision for tester-1 (WG-registration hook): the endpoint already holds a
##    PBS token for tester-1 but the hub has no descriptor — use the explicit „Re-issue PBS
##    credentials" action — save the customer config to retry"
##   That is R-511's exact shape: a customer whose box was rebuilt keeps the ep0 token, the automatic
##   hook refuses, and the product names the one action that helps. It happened by itself on a box
##   installed an hour after the ep0 grant, so the walk handed back the very test that could not be
##   run this morning (the button renders only once a descriptor exists, and there was no host then).
## AND THE ADOPT SUCCEEDED — the ep0 grant proven END TO END (2026-09-16 19:25:36 CEST):
##   „tenantsync: reissue ok for tester-1 (ns=tester-1, token_id=felhom@pbs!tester-1; secret withheld
##    from logs)"
##   „pbsdr ADOPTED for tester-1 (host tester-1-33b6a9, ns tester-1, token_id felhom@pbs!tester-1,
##    gen 2; fresh consume-once secret stored, withheld from logs)"
##   „pbs token secret consumed by host tester-1-33b6a9 (single-use; value withheld from logs)"
##   Two seconds later the box reported back and the hub stored the DR-recipe host half.
##   THE COMPARISON THAT MATTERS: this morning the same action ended with
##     „Process exited with status 255 (stderr: Error: permission check failed — missing
##      Datastore.Modify on /datastore/felhom-offsite)" -> HTTP 502, nothing written.
##   The only thing that changed in between is the narrow grant on ep0 (DatastoreAdmin for the hub's
##   felhom@pbs at the datastore root). R-534 and R-511 are therefore both closed by a live run, not
##   by an argument — and the rebuilt-customer case they describe reproduced BY ITSELF on a fresh box.
