fix(health): fsck survives approved delete and goal proposals

[galuis116]

Supersedes #683, closed for review feedback — same branch, extended per
the reviewer's request.

What changed

_check_decided_proposals in src/vouch/health.py handles
ProposalKind.DELETE proposals in a dedicated first pass instead of
indexing a presence dict that has no entry for that kind, and presence
is now exhaustive over every ProposalKind that owns an artifact of its
own kind — including GOAL, added per review on #683.

Why

presence was keyed on CLAIM/PAGE/ENTITY/RELATION only, so
_check_decided_proposals raised KeyError on any approved DELETE
proposal (presence[pr.kind], since DELETE isn't in presence either).
Delete proposals now get their own first pass checked against
target_kind (reporting decided_delete_invalid_target_kind for a
missing/unrecognized one, or decided_delete_artifact_present if the
target wasn't actually removed), with the ids they legitimately removed
excluded from the second pass so the original creating proposal doesn't
false-positive as decided_missing_artifact once its artifact is
correctly gone.

Review on #683 caught that this was one kind short: an approved GOAL
proposal hits the identical KeyError two lines earlier, at
deleted[pr.kind], since deleted shares presence's same four keys.
Verified against test HEAD:

pr = proposals.propose_goal(store, title="ship the thing", proposed_by="agent")
proposals.approve(store, pr.id, approved_by="reviewer")
health.fsck(store)  # KeyError: <ProposalKind.GOAL: 'goal'>

Goals are fully live (proposals.py files and approves them, lifecycle
maps them to get_goal), so vouch fsck crashes today on any KB with an
approved goal, exactly as it did on an approved delete.

Rather than adding a GOAL line next to DELETE and leaving the same gap
open for a seventh kind, presence is now tied to ProposalKind itself:
an assert derives the expected key set as frozenset(ProposalKind) - {DELETE} (DELETE is checked separately against target_kind, not its
own presence entry) rather than hand-copying members, so a future kind
fails the next test that touches fsck instead of crashing for a user —
the same exhaustiveness shape test_capabilities_matches_jsonl_handlers
already uses for method/handler parity.

Fixes #682

What might break

Nothing for users with an existing .vouch/ directory — no on-disk shape,
kb.* method, or object model change. _check_decided_proposals gains a
goals parameter (internal, not a public signature) threaded from
fsck's existing store.list_goals() call.

VEP

Not applicable — no object model, kb.* method, on-disk layout, bundle
format, or audit-log shape change. A crash fix + exhaustiveness guard
inside fsck's internals.

Tests

• Local make check-equivalent: ruff clean (src + tests); mypy
  clean on health.py; all tests/test_health.py cases pass (29
  total: 25 pre-existing + 1 for the delete-proposal fix + 2 new for
  the goal fix + exhaustiveness pin, plus the earlier
  decided_no_artifact_id DELETE-payload test)
• New / changed behaviour has a test —
  test_fsck_survives_approved_goal_proposal (confirmed it raises
  KeyError on the pre-fix code, passes with the fix) and
  test_check_decided_proposals_presence_covers_every_non_delete_kind
  (pins the exhaustiveness shape)
• CHANGELOG.md updated under ## [Unreleased]