Verify Exchange draft/unlisted publication states and provenance metadata for scanner-derived assets #114

Summary

Three verification items added by §7.10.10. Two share the existing §7.9 publication
verification; the third is new and specific to fleet scale.

1. Can an asset be published in a draft / unlisted / staged state?

Gates the stage tier. Without it, stage collapses into propose and the
ladder has three rungs rather than four.

stage exists for orgs that want scanner output visible and searchable without it
appearing as a curated catalog entry. If Exchange cannot represent "present but not
endorsed," then publishing scanner-derived assets anywhere shared is the wrong
default, and propose (a PR, reviewed by the owning team) is the only safe
non-trivial tier.

This shares the §7.9 row on lifecycle states (draft / published / deprecated), which
already gates require_lifecycle in §6.1.1 and deprecation in §7.5 — one
verification serving four features, so it is high value.

2. Can provenance metadata be attached to a published asset?

Gates the provenance guardrail. Scanner-derived assets must record scanner
version, repo, commit, derivation mode and completeness, so a curator can tell a
bootstrapped entry from a reviewed one. Shares the §7.9 metadata/tags row that also
gates the §7.5 content digest.

If arbitrary metadata cannot be attached, fall back options in preference order:
tags with a reserved prefix; a convention in the description; a sidecar
documentation page. Record which, because the digest and provenance both depend on it.

3. Can all assets in an org be listed efficiently?

New, and specific to §7.10.7's coverage report. The report is bidirectional, so
it needs the full set of published assets in the org — not a search result. Questions:

• Is there an org-wide asset list, or must it be paginated per business group?
• What page size and rate limits apply?
• Does the Exchange GraphQL API (already VERIFIED for asset search) support this,
  or is a REST path needed?
• Is there a cheap way to detect "has anything changed since timestamp T", so a
  scheduled report does not re-list a large catalog every run?

The last one determines whether the coverage report is cheap enough to run weekly on
a catalog with thousands of assets.

What to do

1. Attempt to publish an asset in a draft/unlisted state via REST and via the CLI.
   Record which works and what the state is called.
2. Attempt to attach custom provenance metadata; record the mechanism.
3. List all assets in a test org; record pagination shape, page size, rate limits and
   total latency for a realistically large catalog.
4. Check for a modified-since filter.
5. Capture fixtures and flip the §7.9 / §7.10.10 rows with dates and sources.

Acceptance criteria

• Draft/unlisted state confirmed or ruled out; if ruled out, stage is
  removed from the ladder rather than shipped as a synonym for propose
• Provenance storage mechanism decided and recorded
• Org-wide listing shape, limits and latency recorded
• Modified-since capability confirmed or ruled out; if ruled out, the coverage
  report documents its cost and defaults to a longer cadence
• Fixtures captured for the listing call
• docs/verified-apis.md gains a §7.10 subsection

Unblocks

scan: the autonomy ladder, scan: guardrails — non-downgradable quality gate, A2A propose-only, provenance, and the efficiency design of
scan: coverage report — bidirectional catalog inventory, read-only, ship this first.

References

• Build plan §7.10.10, §7.9, §7.5, §6.1.1 · docs/verified-apis.md §7