v0.11.5

Hermes sessions that were not there

Every Hermes session was missing from the list on a current install, while the database held
them. The SQLite list query filtered on WHERE s.hidden = 0, and hidden is a column the
sessions table no longer has: newer Hermes marks the sessions it hides in archived, and
filters on COALESCE(archived, 0) itself. SQLite fails the whole statement on an unknown
column — it does not degrade, it stops — so the query returned nothing and the list came back
empty.

The column is read off the schema now (pragma_table_info) and the filter is built from
whichever one is present, hidden or archived. With neither, the list runs unfiltered:
showing one session Hermes would have hidden beats reporting a full database as empty.
Listing, messages and the final result all read normally again, on both column names.

An empty list that is not an empty source

Part of why this went unseen is that it did not look like a bug. A source that could not be
read answered with zero records, exactly like a source with nothing in it, and the only trace
was a [WARN] on stderr — so "why is my Hermes history gone" and "you have no Hermes history"
came back as the same answer.

A source says so now. /sessions, /health and the MCP list_sessions tool carry
warnings: [{source, error}] when one could not be read, and nothing at all when they are all
fine. /health is unauthenticated, so it reports what the last scan hit rather than starting
one, and the list ETag folds the warnings in — a source going from readable-and-empty to
unreadable changes no record at all, and a 304 would otherwise hide the one thing that did
change.

Full changelog: v0.11.4...v0.11.5