Draw the tags that have been storable and invisible since the domain landed

`Tag` has been a full item kind for three commits — a table, a migration, a
codec, a merge, a cipher — and `HostSecret.TagIds` has merged per tag so two
people tagging one host both keep theirs. Nothing drew a chip. The tags a
client could store were ones nothing here could see.

Chips on host rows, both heads, from names resolved through the tag list rather
than ids: a tag that does not resolve is left out rather than drawn, because it
means the tag was deleted elsewhere or belongs to a vault this session cannot
read, and a host with one chip fewer is the honest answer where a host wearing
a GUID is not. The id stays on the host, so the chip comes back if the tag does.

The picker is chips that toggle, matching the chips on the row behind it. A
list of names to tick would make the user match an entry to a chip they can see
two inches away. The box under it creates a tag and puts it on straight away,
because that is when a tag is usually wanted — while tagging a host and finding
it does not exist yet. Unlike every other field in that editor it writes to the
keychain immediately, since a host can only name an id that exists; cancelling
therefore leaves the tag behind, which is honest rather than hidden. A name
that already exists is used rather than repeated: two tags called "staging" are
storable and must stay storable, because two people creating one offline is how
it happens, but typing it into a box beside a chip of the same name is a slip.

Renaming and deleting needed a home, or the picker fills with names nobody uses
and never empties. That home is a TAGS category on the keychain screen, where
every other item kind is managed — and renaming is the whole reason a tag is an
item rather than a string repeated inside twenty payloads: it is one write, and
no host is touched. The delete confirmation counts the hosts wearing it, which
is the difference between a tidy-up and losing a filter somebody relies on.

The desktop host editor now scrolls, and that is not a tidy-up. A picker's
height is a chip per tag in the keychain, wrapped, so somebody with fifteen
tags has an editor half again as tall as somebody with three; no fixed height
holds that, and trimming other fields to buy room only moves the failure to
whoever has sixteen. The layout suite caught it the moment its seeder grew tags
— which is why the seeder now creates ten rather than three, enough to drive
the pane onto its cap so the capped shape is what gets measured rather than one
no real keychain produces. The cost is named where it is paid: the harness
skips anything inside a ScrollViewer, so from here it certifies that pane fits
the column rather than that every field in it does.

Two smaller things fell out. Five buttons overflowed the keychain header by a
few pixels, so GENERATE lost the word KEY — its tooltip carries what the word
did. And TotalItemCount had been counting keys and credentials while ALL showed
four kinds; it counts all five now, because a number under a chip that
disagrees with the rows it opens is worse than no number.

An adversarial review of this change found two defects it had introduced, both
green against the full suite. NewTag filed into the "new items go to" picker
while the tag list only ever holds the active vault's — so with a team vault
selected a tag would be created, queued for push, reported as added, and then
invisible, with no row, no count, no picker entry and nothing able to rename or
delete it, because there is no active-vault switcher to go and find it with.
The comment on the host editor's own create path states that exact rule; this
was the one place that broke it, and NewObjectStore, whose list is likewise
active-vault-only, already ignored the picker. And the tag editor was the only
one of five that did not disarm a pending deletion when it opened, so arming a
key's deletion and then pressing + TAG left a live DELETE for an item the user
was no longer looking at, directly above the boxes they were typing into. Both
are fixed, both have a test, and the first was checked against the broken
version before being kept.

The same review caught a doc comment that had been inserted between
SnippetRowViewModel's summary and its declaration, silently taking it over.

Verified by the whole suite on a clean build: 1413 tests over nineteen
projects, none failing. Both heads build. The rectangles the layout suite
cannot reach are phase 9 of docs/manual-checks.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/manual-checks.md

@@ -789,3 +789,48 @@ Walk the sheet's two rows, the editor's fields, both pickers, the checkbox and t
 
 **Failure means:** a control took its size from its glyph. The desktop suite's only tap-target assertion has
 a floor of 20 pixels — set for a mouse — so copying it here would certify a target no thumb can hit.
+
+## Phase 9 — Tag chips and the picker
+
+The desktop half is measured by the layout suite, which now seeds three tags and puts all of them on one
+host so the chip row that wraps is what gets laid out. Two things it still cannot answer, and the phone's
+side of it remains unmeasurable for the reasons in phase 8.
+
+### 9.1 The desktop host editor scrolls rather than losing its buttons
+
+Open a host's editor with a keychain holding a dozen tags.
+
+**Pass:** the editor pane scrolls, and FORGET HOST KEY is reachable at the bottom of it.
+
+**Failure means:** the pane's MaxHeight is gone or the ScrollViewer is. The layout harness skips anything
+inside a ScrollViewer, so from that commit on it certifies the pane fits rather than the fields — it will
+tell you the pane is fine while the last button sits below the window.
+
+### 9.2 A chip toggles and reads as toggled
+
+In the picker, tap a tag on and off.
+
+**Pass:** worn is filled and accent-coloured, unworn is outlined. The difference is legible at a glance from
+normal reading distance, not only side by side.
+
+### 9.3 A tag renamed on one machine renames every chip on the other
+
+Tag two hosts, sync, rename the tag on the other machine, sync back.
+
+**Pass:** both rows show the new name, and neither host shows as having unsynced changes — renaming a tag
+rewrites no host.
+
+**Failure means:** the rename copied a name into the hosts, which is the thing making a tag an item was for.
+
+### 9.4 A deleted tag drops the chip and nothing else
+
+Delete a tag two hosts wear.
+
+**Pass:** the confirmation says how many hosts wear it. After confirming, both rows lose the chip and
+nothing else about them changes. Neither host is queued for push.
+
+### 9.5 The phone's picker is usable with a thumb
+
+On the phone's host editor with several tags: the chips are at least 36 tall, spaced enough that a miss
+lands between them rather than on the wrong tag, and the new-tag box and ADD sit on one row without either
+being squeezed to nothing.