v2.0.1 — the switchboard opens on what a clone would carry

v2.0.0 taught four
surfaces to say whether a capability would survive a clone — and missed the fifth. The Policy
tab is the one place a reader goes to ask what governs this project, and it was still listing
everything on the machine.

Reported from a real repository: a project using a handful of committed skills listed a hundred
and twenty capabilities, every row reading policy.skills.default is allow.

What changed

Every row now carries the verdict and the basis behind it. One that stays on this machine is
badged and dimmed. Under portability: "strict" the table opens narrowed — with a control that
says how many are hidden and brings them back in one click.

What it will never hide is a row somebody wrote a rule about. The narrowing needs two things
to be true at once: the capability would not survive a clone and the policy says nothing about
it. A denied capability, an allow-listed one, and one audit itself requires all stay on screen
wherever they live — this table previews what the guard will do, and a refusal nobody can see is
a lie about that.

Both halves of that condition are proven by mutation, and the browser gate drives the real panel:
it asserts the denied row survives the narrowing, because that is the failure that would look
perfectly fine in a screenshot.

The empty state gained a third answer for the same reason. "Everything discovered here stays on
this machine" is not "nothing matched your filter" — and the Clear-filters button would not
have brought those rows back.

Also

The portability tier was being resolved in three places after 2.0.0.
_config_rules.portability_mode owns the fallback now, and the doctor, the panel's write refusal
and the switchboard all call it.

Nothing about the manifest, the config vocabulary or the gate changed — this is a patch.

Full detail in CHANGELOG.md.