OAS v0.21.1

OAS v0.21.1

OAS v0.21.1 is a corrective release for the v0.21.0 line. There are no new
features and no lock, manifest, or CLI-surface changes: the single correction
below, and the tests that pin it.

Artifact provenance is judged scope-exactly

A deployment chain may legitimately hold the SAME package identity at two
scopes with different source spellings — for example a laptop scope that
acquired oas.okf directly (locked catalog:oas.okf) under a workspace scope
that received the same package through another package's dependency closure
(locked catalog:oas.okf@v2.0.0). Each scope is internally consistent: every
materialized artifact's .oas-installation.json agrees with the lock beside
it.

oas doctor resolved the lock rows for that comparison from the MERGED chain,
where each identity resolves closest-scope-first. Running it at the inner scope
therefore compared the outer scope's artifacts against the inner scope's rows —
rows they were never projected from — and reported the healthy pair as

ERROR: capability oas.okf: materialized capability oas.okf: .oas-installation.json
"source" is "catalog:oas.okf" but the lock records "catalog:oas.okf@v2.0.0" [invalid-lock]

Both doctor renderings (human and --json) now resolve those rows
scope-exactly, the way oas list and oas trust already did: an artifact under
<scope>/.agents/capabilities/installed is judged against <scope>/oas-lock.json
and nothing else — the same discipline v0.20.1 established for doctor's orphan
check. Each package row is also reported with its own scope's source, path, and
commit rather than the nearest scope's.

Trust evaluation carried the same confusion and is corrected identically. When
the closest scope locks a capability it has not materialized, the artifact that
actually activates comes from an outer scope; capabilityTrust compared that
artifact's integrity and provenance against the inner row, so a capability its
own scope had approved resolved as untrusted. Trust now reads the row from the
artifact's own scope.

What is compared is unchanged — source-string equality within the correct scope
— and both directions still fail closed: an artifact that genuinely disagrees
with its own scope's lock is still invalid-lock, and an artifact whose own
scope does not lock it is untrusted even when another scope in the chain locks
that capability id.

Compatibility

• No lockfile, manifest, config, or CLI-surface changes. v0.21.0 locks,
  artifacts, and approvals are unaffected; nothing needs reacquiring.
• Diagnostics only become more precise: chains that never held one package id
  at two scopes see no change.