A skipped sync push still records a success SyncEvent

Follow-up from #160.

LinearAdapter.pushStatusChange now returns without pushing when the Outpost status has no reverse mapping, rather than guessing a Linear state. Returning (not throwing) is deliberate — an unmapped status is a configuration gap, not a transient fault, so retrying it to the DLQ would just be noise.

The side effect is in handleTrackerSync (packages/outpost/queue/src/handlers/tracker-sync.ts): executePush completing without throwing is recorded as

await engine.recordSyncEvent(..., 'success');

So the sync event log shows a successful push for an operation that intentionally did nothing. The adapter warns to the console, but the audit trail — which is what the /sync dashboard renders — disagrees with reality.

Options:

• a third SyncEvent status (skipped) alongside success/failure/pending/conflict
• have push operations return a result the handler can distinguish, instead of Promise<void>
• record success with a reason in the event metadata

The middle option is the most honest but the widest — it touches the InternalTracker interface and both adapters.

Not urgent: the operator does get told at the point of action, because POST /api/sync/force returns skipped + unmappable and the dashboard surfaces them. This is about the durable log rather than the immediate feedback.

Start in packages/outpost/queue/src/handlers/tracker-sync.ts, reading handleTrackerSync and executePush, then trace the InternalTracker interface through both adapters. Use POST /api/sync/force to compare skipped operations with the durable sync event. Done means an intentionally skipped push is no longer recorded as a successful event while immediate skipped feedback remains intact.