Stale proposals (S-001-1 to S-001-9) #97

Builds part of spec S-001, docs/specs/001-stale-proposals.md: the acceptance criteria below. Each needs a test that names its id (test_s001_<k>_..., or a proves: S-001-1 comment line).

• S-001-1: A proposed decision whose basis names host hz1 observed at T1 reads "stale": true with "staleHosts": ["hz1"] in decisions list once hz1's observation file in the basis folder says observedAt T2 later than T1
• S-001-2: The same decision reads "stale": false and no staleHosts when the observation file still says T1, when it is missing, or when the basis names no host
• S-001-3: A decision with any status other than proposed has no stale or staleHosts key in decisions list, decisions show, or cloudfall why output, whatever the observations say
• S-001-4: decisions list --stale returns only the stale decisions, and decisions list --stale --status proposed returns the same set
• S-001-5: cloudfall why --stale returns only the stale decisions and reports stale and staleHosts as decisions list does
• S-001-6: decisions show <id> reports stale and staleHosts for a stale proposed decision
• S-001-7: Working out staleness writes nothing: the decision record file's bytes are unchanged after decisions list, decisions show, and cloudfall why
• S-001-8: decisions approve on a stale proposal names each stale host and its newer observedAt in the attestation prompt and, once the id is typed, runs as it does for a fresh proposal
• S-001-9: An observation file in the basis folder that isn't valid JSON makes decisions list exit RECORD_INVALID with an error naming the file