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>

src/DodoSSH.Client.App/Views/HostSidebar.axaml

@@ -163,6 +163,28 @@
                            Foreground="{StaticResource TextFaint}"
                            IsVisible="{Binding HasVaultBadge}" />
               </StackPanel>
+
+              <!--
+                The tags this host wears. A third line rather than more on the second, because a host can
+                wear several and the second line's three facts are fixed-width where these are not — one
+                long tag would push the vault badge off the end of a 268-pixel column.
+
+                Names, not ids: a tag the vault cannot resolve is left out rather than drawn. See
+                HostRowViewModel.TagLabels.
+              -->
+              <ItemsControl ItemsSource="{Binding TagLabels}" IsVisible="{Binding HasTags}"
+                            Margin="0,1,0,0">
+                <ItemsControl.ItemsPanel>
+                  <ItemsPanelTemplate><WrapPanel /></ItemsPanelTemplate>
+                </ItemsControl.ItemsPanel>
+                <ItemsControl.ItemTemplate>
+                  <DataTemplate x:DataType="x:String">
+                    <Border Classes="chip" Padding="5,0" Margin="0,0,4,0">
+                      <TextBlock Text="{Binding}" FontSize="8.5" />
+                    </Border>
+                  </DataTemplate>
+                </ItemsControl.ItemTemplate>
+              </ItemsControl>
             </StackPanel>
           </Grid>
         </DataTemplate>
@@ -170,10 +192,27 @@
       </ListBox.DataTemplates>
     </ListBox>
 
-    <!-- The editor doubles as the "add" form; there is no separate dialog. -->
+    <!--
+      The editor doubles as the "add" form; there is no separate dialog.
+
+      ◆ It scrolls, and it did not until the tag picker arrived. The reason is that a picker's height is not
+      a property of the design: it 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 cost is real and worth naming. The layout harness skips any control with a ScrollViewer in its
+      ancestry — see LayoutHarness.IsScrollable — so from here on it certifies that this *pane* fits the
+      column rather than that every field inside it does. That is the true claim about a pane that scrolls.
+      The MaxHeight is stated rather than left to the row for the same reason: it is what keeps the pane
+      itself inside the window, which is the part the harness still watches. 300 is what the minimum window
+      affords once the filter, the heading and the button strip have taken theirs, with enough left that the
+      host list above does not vanish — the point of a column this narrow is that the list stays visible
+      while a host in it is edited.
+    -->
     <Border Grid.Row="3" Padding="10" Background="{StaticResource Chrome}"
             BorderBrush="{StaticResource BorderSubtle}" BorderThickness="0,1,0,0"
             IsVisible="{Binding IsEditing}">
+      <ScrollViewer MaxHeight="300" HorizontalScrollBarVisibility="Disabled">
       <StackPanel Spacing="6">
         <TextBox Text="{Binding EditorLabel}" PlaceholderText="name" />
         <TextBox Text="{Binding EditorHostname}" PlaceholderText="hostname or address" />
@@ -230,6 +269,48 @@
             </DataTemplate>
           </ComboBox.ItemTemplate>
         </ComboBox>
+        <!--
+          ◆ The tags this host wears. Chips that toggle rather than a multi-select list, because a chip is
+          what a tag looks like on the row two inches above — a list of names to tick would make the user
+          match an entry to a chip they can already see.
+
+          The box under them creates one and puts it on straight away. That is where a tag is usually
+          wanted: while tagging a host and finding it does not exist yet. Unlike every other field here it
+          writes to the keychain immediately, because a host can only name a tag that has an id — so
+          cancelling this editor leaves the tag behind, which is honest rather than hidden. Renaming and
+          deleting are on the keychain screen, where every other item kind is managed.
+        -->
+        <ItemsControl ItemsSource="{Binding EditorTagChoices}" IsVisible="{Binding HasTagChoices}"
+                      Margin="0,4,0,0">
+          <ItemsControl.ItemsPanel>
+            <ItemsPanelTemplate><WrapPanel /></ItemsPanelTemplate>
+          </ItemsControl.ItemsPanel>
+          <ItemsControl.ItemTemplate>
+            <DataTemplate x:DataType="vm:TagChoice">
+              <!--
+                Worn is filled, unworn is outlined. One control per tag with two states rather than a
+                checkbox beside a label: the state and the name occupy the same object, so a row of them
+                reads as the host's tags rather than as a form about them.
+              -->
+              <Button Classes="chiptoggle" Classes.worn="{Binding IsWorn}" Margin="0,0,4,4"
+                      Command="{Binding $parent[ItemsControl].((vm:VaultViewModel)DataContext).ToggleEditorTagCommand}"
+                      CommandParameter="{Binding}">
+                <TextBlock Text="{Binding Label}" FontSize="9.5" />
+              </Button>
+            </DataTemplate>
+          </ItemsControl.ItemTemplate>
+        </ItemsControl>
+
+        <Grid ColumnDefinitions="*,6,Auto">
+          <TextBox Grid.Column="0" Text="{Binding EditorNewTag}" PlaceholderText="new tag"
+                   FontSize="11" MinHeight="26" Padding="8,3">
+            <TextBox.KeyBindings>
+              <KeyBinding Gesture="Enter" Command="{Binding AddEditorTagCommand}" />
+            </TextBox.KeyBindings>
+          </TextBox>
+          <Button Grid.Column="2" Classes="ghost" Content="ADD" Command="{Binding AddEditorTagCommand}" />
+        </Grid>
+
         <CheckBox IsChecked="{Binding EditorRelayEnabled}"
                   Content="Connect through the server relay" />
         <!--
@@ -255,6 +336,7 @@
                 IsVisible="{Binding CanForgetHostKey}"
                 ToolTip.Tip="Removes the pinned key for this host's address, so the next connection asks you to check its fingerprint again." />
       </StackPanel>
+      </ScrollViewer>
     </Border>
 
     <Border Grid.Row="4" Padding="10,8" BorderBrush="{StaticResource BorderSubtle}" BorderThickness="0,1,0,0"

src/DodoSSH.Client.App/Views/VaultScreen.axaml

@@ -76,6 +76,23 @@
             is something somebody creates, edits and keeps a secret for, which is what the other two
             categories are. A pin is a decision recorded at connect time and is not.
           -->
+          <!--
+            Tags. The odd category: it is the only one holding nothing secret — a tag is a name. It is here
+            because the reason a tag is an item at all is that renaming it should be one write instead of
+            twenty, and a rename needs somewhere to happen; so does deleting, or the host editor's picker
+            fills with names nobody uses and never empties.
+          -->
+          <Button Classes="flat cat" Command="{Binding ShowSectionCommand}"
+                  CommandParameter="{x:Static vm:VaultSection.Tags}"
+                  Classes.active="{Binding ShowsTags}">
+            <Grid ColumnDefinitions="Auto,*,Auto">
+              <Border Grid.Column="0" Classes="rowmark catmark" />
+              <TextBlock Grid.Column="1" Text="TAGS" Margin="12,0,0,0" />
+              <TextBlock Grid.Column="2" Text="{Binding Tags.Count}"
+                         Foreground="{StaticResource TextFaint}" />
+            </Grid>
+          </Button>
+
           <Button Classes="flat cat" Command="{Binding ShowSectionCommand}"
                   CommandParameter="{x:Static vm:VaultSection.Buckets}"
                   Classes.active="{Binding ShowsBuckets}">
@@ -152,12 +169,18 @@
               Always offered. Every category left on this screen is one things can be added to — the one
               that was not, HOST KEYS, is now its own screen, and a pin still cannot be typed in there
               either. See KnownHostsScreen.
+
+              GENERATE lost the word KEY when a fifth button arrived: five of these overflow an 1016-wide
+              window's header by a few pixels, and the layout suite catches it. Its tooltip carries what the
+              word did, and the two key buttons are adjacent, so which one generates is not in doubt.
             -->
-            <Button Classes="ghost" Content="GENERATE KEY" Command="{Binding NewGeneratedKeyCommand}"
+            <Button Classes="ghost" Content="GENERATE" Command="{Binding NewGeneratedKeyCommand}"
                     ToolTip.Tip="Makes a new key pair here, so the private half never becomes a file on this disk." />
             <Button Classes="ghost" Content="+ SSH KEY" Command="{Binding NewKeyCommand}"
                     ToolTip.Tip="Pastes in a key you already have." />
             <Button Classes="ghost" Content="+ PASSWORD" Command="{Binding NewCredentialCommand}" />
+            <Button Classes="ghost" Content="+ TAG" Command="{Binding NewTagCommand}"
+                    ToolTip.Tip="A name to put on hosts. Usually made from a host's editor instead; this is for setting a scheme up before there is anything to put it on." />
             <Button Classes="accent" Content="+ BUCKET" Command="{Binding NewObjectStoreCommand}"
                     ToolTip.Tip="An S3-compatible bucket, to browse beside a host on the Files screen." />
           </StackPanel>
@@ -384,6 +407,26 @@
             </StackPanel>
           </StackPanel>
 
+          <!--
+            The tag editor, and the whole of it is one box. What it does not have is the point: renaming a
+            tag touches no host, because every host wearing it names its id. That is the entire reason a tag
+            is an item rather than a string repeated inside twenty payloads.
+          -->
+          <StackPanel Spacing="6" IsVisible="{Binding IsEditingTag}">
+            <TextBlock Classes="label" Text="TAG" Margin="0,0,0,4" />
+            <TextBox Text="{Binding TagEditorLabel}" PlaceholderText="name">
+              <TextBox.KeyBindings>
+                <KeyBinding Gesture="Enter" Command="{Binding SaveTagCommand}" />
+              </TextBox.KeyBindings>
+            </TextBox>
+            <TextBlock Classes="hint" FontSize="9.5"
+                       Text="Renaming a tag changes it everywhere at once. No host is rewritten — each one names this tag rather than repeating its name." />
+            <StackPanel Orientation="Horizontal" Spacing="6">
+              <Button Classes="accent" Content="SAVE" Command="{Binding SaveTagCommand}" />
+              <Button Classes="ghost" Content="CANCEL" Command="{Binding CancelTagEditCommand}" />
+            </StackPanel>
+          </StackPanel>
+
           <!-- The bucket editor. -->
           <StackPanel Spacing="6" IsVisible="{Binding IsEditingObjectStore}">
             <TextBlock Classes="label" Text="BUCKET" Margin="0,0,0,4" />