Unify sync-stage metadata across error classification, notifications, and metrics

[darron]

Follow-up from PR #166 (merged as 218c1035).

The sync-stage set is maintained independently in three places:

• internal/syncjob/stage_error.go: parseKnownStage
• internal/notify/catalog.go: knownSyncStages
• internal/metrics/metrics.go: notificationMetricFailureTypes

Adding, renaming, or removing a stage now requires synchronized edits. If the lists drift:

• WrapStageError can fail to preserve the stage identity.
• Notification classification can fall back to sync.unknown.
• Notification metrics can normalize a valid stage failure to sync.unknown.

PR #166 required parallel updates for the Bluesky and Mastodon bookmark stages, which exposed the maintenance risk.

Proposed resolution:

• Define one canonical stage metadata source, or add a generated/compile-time mechanism that derives the consumer registries.
• Keep the existing public failure type and error-code names stable.
• Add a regression test that fails when an enabled sync stage is missing from stage-error recognition, notification catalog lookup, or notification metric validation.
• Document any intentional distinction between internal stage IDs and emitted metric/source names.

[darron]

I filed #167 for this same problem 15 seconds before this issue was opened. Closing mine as the
duplicate — this one has the better acceptance criteria. Two things from #167 that are load-bearing
and are not captured here:

1. The first proposed resolution is blocked as written

"Define one canonical stage metadata source" cannot be done by exporting the list from syncjob and
having the other two derive from it: syncjob already imports metrics
(internal/syncjob/metrics.go:9, for metrics.RunContext), so metrics importing syncjob is an
import cycle. notify and metrics currently have no dependency on each other or on syncjob.

A real single source of truth therefore needs a new leaf package (e.g. internal/syncstage)
that imports nothing internal, with syncjob, notify, and metrics all deriving from it.

The regression-test bullet has no such constraint — it only needs exported accessors
(notify.KnownFailureTypes() already exists at internal/notify/catalog.go:130) and a test in a
package that can see all three, e.g. internal/app. That is worth landing on its own even if the
canonical-source refactor is deferred, since it converts a silent runtime degradation into a failing
test.

2. There is a fourth list

The stage set is maintained in four places, not three. The missing one is upstream of the other
three:

• internal/syncjob/stage_plan.go:15-28 — the syncStageID constants and defaultSyncStagePlan

It matters for the acceptance criteria: "fails when an enabled sync stage is missing from ..." needs
a definition of enabled, and that definition lives in defaultSyncStagePlan. If the test derives
its expected set from parseKnownStage rather than from the plan, a stage that runs but was never
added to parseKnownStage still passes.

Failure modes, with the exact mechanism

Verified at 218c103. For a new stage foo:

• Missing from parseKnownStage — WrapStageError returns the cause unchanged
  (internal/syncjob/stage_error.go:16-19), so no *StageError is ever constructed.
  classifyScheduledFailure cannot match it (internal/app/notify_classify.go:143-151) and falls
  through to sync.unknown. stageErrorCount (internal/syncjob/metrics.go:638-654) also counts
  zero, so counts.stages_error is wrong too.
• Missing from notify.knownSyncStages — LookupStageFailure returns false
  (internal/notify/catalog.go:134-141), so even with a correct *StageError the notification is
  still sync.unknown.
• Missing from metrics.notificationMetricFailureTypes — NotificationDeliveryCompletedEvent
  rewrites failure_type to "sync.unknown" (internal/metrics/metrics.go:94-96). The delivered
  notification is correct but the metrics record is not — and metrics.jsonl is the file that was
  used to diagnose the 2026-08-17 14:31 run in Continue sync all after individual stage failures #165, so a wrong value there costs debugging time
  later.

Every one of these produces a plausible-looking sync.unknown rather than an obvious break, which
is why the guard test matters more than its size suggests.

Confirming there is no coverage today:

$ grep -rn 'knownSyncStages\|parseKnownStage\|notificationMetricFailureTypes' --include='*_test.go' .
$ echo $?
1