railcall.ai/verify still rejects railcall_team_command_receipt.v1 - the delegated-send receipt the station emits has no public verifier

What happens

The browser verifier at railcall.ai/verify accepts exactly five schema families. Its own message to the user says:

this validator supports railcall_egress_receipt.v1, railcall_witness_anchor.v1, railcall_command_receipt.v1, railcall_<provider>_apply_receipt.v1, and railcall_workflow_dagrun_receipt.v1/v2

The acceptance test in the deployed bundle is:

"railcall_command_receipt.v1"===N ? j="railcall_command_receipt.v1"
  : "string"==typeof N && /^railcall_[a-z0-9_]+_apply_receipt[.]v1$/.test(N) && (j=N)

station-v1.5.8 emits railcall_team_command_receipt.v1 from live code - workbench/workflow_engine.py:1939, the receipt for a DELEGATED team command (carries grant_id, use_id, holder_pubkey, relay_touched). That schema id is not an _apply_receipt, so it matches neither branch and falls into the unknown path.

Receipts the station emits today that the deployed verifier cannot verify:

railcall_team_command_receipt.v1     <- delegated team command
railcall_workflow_receipt.v1 / .v2
railcall_workflow_run_receipt.v1
railcall_batch_receipt.v1
railcall_http_receipt.v1
railcall_transform_receipt.v1

Why it matters

The team command receipt is the one an outside party is most likely to be handed: it is the artifact proving a teammate's request ran under a credential share, on someone else's station, with a human approval on the holder's side. Who approved is saved is exactly the claim a buyer would want to check independently, and the public verifier is where they would check it. The workflow receipts are the other everyday artifacts with no public verification path - only the DAG-run family made it in.

Repro

Run any delegated team command through a share grant (Studio, Team, Uses). The emitting station writes a railcall_team_command_receipt.v1.
Paste that receipt into https://railcall.ai/verify.
It reports the schema as not verifiable there and stops. CLI verify and in-Studio verify both handle it.

The verifier half needs no station to confirm: fetch the /verify page chunks and grep for the schema list quoted above.

Being fair to the current build

This is a coverage gap, not a false FAIL. The deployed page is careful about it - "An unknown schema is not a fail of the receipt, just a limitation here" - which is a real improvement over a receipt reading as failing. The per-provider apply receipts and the DAG-run family clearly landed in the same pass. The team receipt did not come with them, and it is the one carrying the team governance evidence.

The tarball ships docs/backlog-2026-08-24-walkthrough.md, which lists the intended family as railcall_*_apply_receipt.v1/v2, railcall_command_receipt.v1, railcall_team_command_receipt.v1, workflow receipts and team approval blocks. Three of those are live; team_command_receipt and the .v2 apply spelling are not - the regex pins [.]v1$.

Suggested fix

Add railcall_team_command_receipt.v1 to the exact-match set with its own field list (node_id, command, provider, grant_id, use_id, holder_pubkey, args_sha, output_sha, run_id, workflow_id, emitted_at), same canonicalization as the rest: deep-sorted JSON minus signature, sha256, Ed25519 over the UTF-8 hex digest. Widening the regex to [.]v[12]$ covers the v2 spelling in the same change.