Decide whether WAITING_ON_CUSTOMER / WAITING_ON_TEAM should map to Linear states

Product decision, surfaced by #160.

TicketStatus has six values. createLinearStatusMap() covers four:

Triage:        OPEN
Backlog:       OPEN
Todo:          OPEN
'In Progress': IN_PROGRESS
Done:          RESOLVED
Canceled:      CLOSED

WAITING_ON_CUSTOMER and WAITING_ON_TEAM have no reverse mapping. Before #160 they silently resolved to Triage via StatusMap.fromOutpost's fall-back-to-first-entry, which meant a waiting ticket dragged its Linear issue back to Triage and reported a successful sync.

#160 makes the adapter skip those pushes instead, because choosing a Linear state for "waiting on customer" is a product call, not a code one. That's the safe default, but it's a default — those tickets now simply don't sync their status, and the operator is told via the force-sync response and a log warning.

The alternatives:

1. Keep skipping. Waiting states are Outpost-internal and have no meaningful Linear equivalent. Costs nothing, but the two systems visibly diverge for tickets in those states.
2. Map both to a real state — Todo, Backlog, or a dedicated Linear state if the team adds one. Keeps the systems aligned at the cost of collapsing a distinction Outpost tracks.
3. Map them differently — e.g. WAITING_ON_TEAM → Todo (ours to act on), WAITING_ON_CUSTOMER → Backlog (blocked externally).

Option 3 is probably closest to what the states actually mean, but it depends on how the team uses the Linear board.

Whichever way this lands, the mapping should go in createLinearStatusMap() so it's visible next to the rest, not left to the fallback.

Start at createLinearStatusMap() and read the status handling introduced by #160, including StatusMap.fromOutpost, the force-sync response, and the log warning. Resolve with the team whether waiting states stay skipped or map to Linear states, then place the chosen mapping in createLinearStatusMap(). Done means the product decision is reflected in the adapter and its reported sync behavior.