Look the host list up by name, rather than off a field that is never assigned

Nightly 0.0.0-alpha.0.133 died before its first frame. The long press I added
attached itself in HostsScreen's constructor through the field the Avalonia name
generator declares for `x:Name` — and that field is assigned by the generated
InitializeComponent, which no view in this repository calls. Every one of them
loads its XAML directly. So the field compiles, resolves in the editor, and is
null at run time; PhoneShell builds this control on the way up, so the
NullReferenceException took the launch rather than the hosts screen.

PhoneShell and TerminalScreen both use FindControl, and PhoneShell carries a
<remarks> saying exactly this and naming exactly this consequence. I read neither
and wrote the field.

So the rule is in docs/platform-flags.md now as well. A comment on the control
that already got it right is not where somebody writing a new one is looking,
which is the whole of why two correct examples and one warning were not enough.

And phase 8 opens with "it launches at all". Nothing on this head is covered by a
test — no test project, no headless surface — so a view that throws while being
built takes the launch with it and no gate anywhere says so. Thirty seconds, and
it would have caught this one before it was published.

docs/platform-flags.md

@@ -366,6 +366,22 @@ like packaging.
 **Linux ships AppImage and Flatpak first**, specifically so the WebKit runtime is bundled rather
 than assumed present on the user's machine.
 
+**A field generated for `x:Name` is null in every view in this repository, and using one is a crash rather
+than a mistake you can see.** The Avalonia name generator declares a field per `x:Name` and assigns it
+inside the `InitializeComponent` it also generates. **No view here calls that method** — every one of them
+loads its XAML directly with `AvaloniaXamlLoader.Load(this)`, on both heads. So the field exists, compiles,
+resolves in the editor, and is null at run time.
+
+What that costs depends on where it is touched. In a constructor it is a `NullReferenceException` while the
+control is being built, and a control being built by `PhoneShell` on the way up takes the whole launch with
+it: the application dies before the first frame, with a stack that names the view rather than the name.
+Nightly `0.0.0-alpha.0.133` shipped exactly that, from one line in `HostsScreen`'s constructor.
+
+`this.FindControl<T>("Name")!` is the idiom, and it is what `PhoneShell`, `TerminalScreen` and `HostsScreen`
+all use. Two of those three carried a `<remarks>` warning about it before the third did it anyway, which is
+why it is written here as well: a comment on the control that already got it right is not where somebody
+writing a new one is looking.
+
 **Opening the system browser depends on the platform handler.** `SystemBrowserLauncher` uses
 `UseShellExecute`, which delegates to `ShellExecute` on Windows, `open` on macOS and `xdg-open` on
 Linux. *Unverified off Windows:* `xdg-open` comes from `xdg-utils`, which is not guaranteed on a