fix(host-cli): make the ring-VRF e2e re-runnable and say why a prefix is refused

[filvecchiato]

Two fixes for the report that make e2e-cross-product-ringvrf passes once and then never again.

It stranded its own identity. The script discarded --base-path on exit while
registering a lite username on a real chain. That directory held the only copy of the
account owning the name, so run 1 took headless and every later run asked for it with
a fresh mnemonic and was refused. The storage sibling can discard its state because it
never reaches a chain; this one can't. State now lives under target/, overridable with
E2E_STATE_DIR for a deliberately fresh identity.

The refusal pointed the wrong way. lite_username_base rejected a short prefix and a
non-lowercase one with the same "at least 6 lowercase ASCII letters" message, so the
obvious way to make a prefix unique — appending digits or a hyphen — reported as too
short. Verified before and after:

12-lowercase   -> Ok("abcdefghijkl")
letters+digits -> Err(... at least 6 lowercase ASCII letters)   # before
with hyphen    -> Err(... at least 6 lowercase ASCII letters)   # before

Verification

• cargo test -p truapi-host-cli green; new a_long_enough_prefix_is_not_refused_for_its_length
  covers the three shapes above
• cargo +nightly fmt --check and clippy clean
• bash -n on the script

I have not run make e2e-cross-product-ringvrf itself — it registers against
paseo-next-v2, and doing so would consume another on-chain username. The state-directory
change is reasoned, not observed; worth one real run before merging.

[github-actions]

CI Status: 14 required jobs green, 11 passed and 3 skipped by path filter.

All job results

job	result
android-bindings	skipped
changes	success
codegen	success
e2e	skipped
explorer	success
ios-bindings	success
ios-swift	skipped
licenses	success
playground	success
rust	success
ts-client	success
ts-debugger	success
ts-host	success
wasm-provider	success

_{Commit 49b09292 · run log}

[decrypto21]

Yes — locally but against live paseo-next-v2, and that was the bit I hadn't joined up. Registering the ring-VRF key resolves a ring on People and the account claims a lite username on chain, so the run leaves real state behind while the script was throwing away the only copy of the account that owned it. Your diagnosis is right and sharper than mine: I had "fresh base path, so it asks for a new name" and stopped there, missing that discarding the directory strands the name permanently because nothing can prove ownership afterwards.

I was also wrong about the flag. I reported it as "the argv is right but something downstream reads a different value" — it wasn't, the value was fine and the error message was pointing the wrong way. hrce2e plus six letters would have worked; I appended digits and believed the length complaint.

Ran #752 twice, cherry-picked onto the branch:

run 1 (fresh state, prefix supplied)        EXIT=0
run 2 (no prefix, reusing the kept state)   EXIT=0

Same signature both runs, 0xdc044fe6…d8460b, which is the account actually persisting rather than being re-created.

One gap it leaves, which I pushed a commit for. It repairs a machine that has not stranded the name yet, but not one that already has: the kept state directory starts empty, so the first run still asks for headless and the script has no way to pass anything else. I added an E2E_LITE_USERNAME_PREFIX passthrough, consulted only when the state directory holds no account. That is what let run 1 happen here.

Two things you may not know. The storage sibling still does mktemp + trap rm -rf — it gets away with it today because it never registers a name, but it is the same shape. And none of this runs in CI: no workflow references battery.sh or the cross-product scripts, and the one e2e job in ci.yml is if: false. So a local run is the only evidence this path works, which makes re-runnability matter more than I first thought.

Two follow-ons, both from chasing this.

I rebased onto 2c176869 rather than keeping the merge you made from the Update branch button, so the stack stays linear — your merge commit is preserved underneath and the push was a fast-forward, nothing of yours was overwritten.

And the pairing wire path works now, which closes the one review item of yours I had left open. It needed --product-config on pairing-host: the app side consults the grant before delegating, so without a local config its only source is dotNS and an undeployed pair is refused before it ever reaches the authority. #524 scopes the flag as "the CLI reads trustedProducts", and #702 describes it as truapi-host --product-config without naming a role, so this reads as a gap in #702 rather than a new feature — your call. With it, two hosts and a real handshake:

granted over the pairing wire  dim2.paseo -> peopl.paseo   0x3655a1d7…c26e09
refused                        stash.paseo                 NotAllowlisted

That is on t14-pairing-wire-e2e locally, deliberately not in #730. Happy to raise it separately against your area if you want it.

[decrypto21]

Included as 14fa71a with your authorship — nothing left to merge here.