the daemon reads projects.yml without asking its kind — a FIFO wedges the event loop at startup, on every project touch, and on list_projects/remove_project #2105

Four readers of ~/.emrg/projects.yml open it without asking its kind, and every one of
them runs on the daemon's event loop:

read_text on a FIFO waits at the open for a writer and raises nothing, so no handler
can fire and the call never returns. These are synchronous calls inside coroutines the
daemon awaits, so the block is the whole daemon: every client stops being answered, no
turn runs, and the only recovery is a restart — which belongs to the host. The registry is
also the first thing a GUI or TUI asks for on connect, so the wedge arrives with the first
frame a client sends.

Measured 2026-10-11 (cyc20261011-173122) on master 60541e39, one arm per site bounded
by tests/bounded_read.within (5 s), each with a pipe-free control in the same shape:

The two directions need different answers, and the difference is not cosmetic:

• The three readers refuse through the except OSError each already has for a registry
  it cannot read, so no new branch is added and the reading the caller gets is the one its
  contract already promised for an unreadable file.
• _touch_project reads the registry and then rewrites it. Letting it fall into its
  existing "rebuilding" branch would answer a host file it could not read with an empty
  registry and delete every project the host had registered, in one write, to report a
  problem it never mentioned. It skips the registration instead — the file keeps what it
  had — and the warning names the kind.

This is the same condition #2062 named for the three file tools and #2073 for the
daemon's own readers; #2081 is the shared predicate (_non_regular_kind), and the
refusal here is that predicate plus one line, so this member is the last spelling of it in
this module rather than a second one.