cli: own an explicit --log before the session starts; a lock read that fails is a problem row

[ohdearquant]

Three things the source review of the app part turned up (records 89a5bcb4, 51130218).

• An explicit --log is owned before the session starts. lion chat --log X checked that X did not exist and then started the session; the log was created later, by the console's first write, so two starts naming one path in that window shared a log. The path is now created here, exclusively, as fresh_log does for the automatic name; a second start naming it is refused, and a start that fails before anything is logged removes the log it created, which is now the only log it can have.
• A lock read that fails is that resident's problem, not a holder and not the whole table. _held read every failed flock as a live holder, and an os.open or os.read that failed escaped resident, so one resident's unreadable pid file took every row down. Only a refused shared lock is a holder now; any other failure raises, resident writes it on that row (agent.pid: <error>, serving false, pid unknown), and the control surface reads it as busy, so a restart takes force rather than cutting a wake short on a guess.
• Two help strings and one ADR pointer said what the code does not: the patch is applied with plain git apply, the areas registry carries chair and desks, and the lion context command's tests are in tests/test_context.py.

Tests: the log exists at session entry and a second start naming it is refused; a lock call failing with ENOLCK and a pid file that cannot be opened each land on their own row while the other resident keeps its row, with a working-lock control between. Both arms fail on the code before this change.