trust: the promised key-registration path does not exist (spec 09 §5 add-registry TOFU + `tebako key import` unimplemented)

[ronaldtse]

The gap

A third-party-signed payload fails closed with exit 72 on a fresh
TEBAKO_HOME, and the failure text sends the user to a command that
does not exist:

• crates/tebako-shim/src/runtime.rs: "…if you trust this signer,
  register its public key with tebako key import" — there is no
  key verb in tebako, tebako-pkg, or tfs-cli.
• crates/tebako-cli/src/install.rs: "…register the publisher's key
  (~/.tebako/keyring/trusted.pgp), then retry; nothing was cached" —
  accurate about the location, but the product offers no verb that
  puts a key there; the user must hand-assemble a binary
  concatenated-TPK keyring out of band.

Spec 09 §5 already designs the real channel — it is simply not
implemented:

1. The registry index carries a signing: block at its head (armored
   public key, fingerprint, optional canonical key URL).
2. tebako add-registry fetches the index, displays the fingerprint
   and the cross-check URLs, and asks for confirmation (TOFU). On
   confirmation the key is pinned to
   $TEBAKO_HOME/trust/<fingerprint>.pub, keyed by the registry ref.
   --yes flows supply the expected fingerprint out of band — never a
   blind yes.

Today add-registry records the ref and primes the dispatch cache —
nothing more — and Registry::from_yaml has no head signing: block
to read.

Repro

1. Publish any slice signed with a non-tamatebako key; pin the primary
   keyid in the registry entry as usual.
2. On a fresh TEBAKO_HOME: tebako add-registry tfs:github:<org>/<repo>
   then tebako install <payload>@<version>.
3. The slice's signature is cryptographically valid, the pin matches
   the primary — and the install still fails [72]
   (… is signed by <subkey>, which is not in the trusted keyring),
   because nothing ever imported the publisher's public key.

Ask

• Implement the spec 09 §5 registry-head signing: block +
  add-registry TOFU pin (display fingerprint, cross-check URLs,
  explicit confirm; --yes requires the expected fingerprint via
  env/config).
• Add the tebako key import <armored-key> verb the shim's error text
  already promises (a thin wrap of tebako_signer::register_trusted),
  or fix the error text to name the verb that ships.
• Align the three trust-failure texts (shim runtime, shim slices, CLI
  install) on the same remediation wording.

Until then the only remediation is out-of-band: place the publisher's
binary public key in $TEBAKO_HOME/keyring/trusted.pgp by hand, or set
TEBAKO_TRUSTED_ROOT to a file carrying the armored key — both
undocumented for end users.