fix(schedule): pin the job's state and log, and report failed runs (#81)

The launchd plist took its log path from the creating shell's VANA_HOME but
started the job without it, so a schedule made from a test state collected
into ~/.vana while logging into a /tmp home the OS wiped. With --quiet the
run printed nothing and exited 0 even when every sync failed.

- schedule add writes EnvironmentVariables (VANA_HOME always, plus network,
  account and server selection when set; never tokens) and puts the log in
  that home's logs dir; the cron line carries the same env. Re-running add
  repairs an outdated job, keeps its interval and says what was wrong.
- schedule list shows the state and log the job uses and warns when the job
  is outdated or serves a different state than the current shell.
- collect --all exits 1 when any source failed to collect or sync (5 when
  the only problem is that no Personal Server answered) and names each
  failed source on stderr, even under --quiet.
- A scheduled run records its outcome in state and vana status shows the
  last one, with the failure count and log path when it failed.

Claude-Session: https://claude.ai/code/session_01Fcv6uEy4zcXaigzDNxeW3j

Author: volod-vana

docs/CLI-EXIT-CODE-MATRIX.md

@@ -38,6 +38,11 @@ field carries the finer-grained reason (`owner_not_ready`, `grant_revoked`,
   `exitCodeForOutcome`; the mapping for their statuses is:
   `personal_server_unavailable -> 5`, `needs_input -> 7`, success -> `0`,
   everything else `1`.
+- `collect --all` (what the schedule runs) exits `0` only when every source
+  it touched collected and synced. A source whose sync failed, even though
+  its data was kept locally, makes it exit `1`; when the only problem is
+  that no Personal Server answered, it exits `5`. Each failed source is
+  named on stderr, also under `--quiet`.
 - The builder command group (`vana app ...`) emits through the mapper from
   its first release.