LinearAdapter.pushNewIssue still guesses an initial state for unmapped statuses

Follow-up from #160.

#160 made LinearAdapter.pushStatusChange refuse to guess: StatusMap.fromOutpost falls back to the first entry of its config for any Outpost status with no reverse mapping, and createLinearStatusMap() covers four of TicketStatus's six values, so WAITING_ON_CUSTOMER and WAITING_ON_TEAM both resolved to Triage.

pushNewIssue was deliberately left unguarded (packages/outpost/shared/src/sync/adapters/linear.ts:208):

const stateId = await this.resolveWorkflowStateId(
    this.mapStatusFromOutpost(ticket.status),
);

The reasoning: creating an issue requires picking some initial state, and Triage is a defensible default for a brand-new issue — unlike a status change, where guessing overwrites a state someone deliberately set.

It's arguable though, and it leaves the two paths inconsistent. Worth an explicit decision:

• keep the fallback for creation, and say so in a comment at the call site, or
• pass no stateId when the status is unmapped and let Linear apply the team default, or
• resolve it together with the broader "should WAITING_ON_* map to real Linear states" question

Low urgency — the failure mode is a new issue landing in the wrong column, not an existing one being silently moved.

Start in packages/outpost/shared/src/sync/adapters/linear.ts at line 208, then read pushStatusChange and StatusMap.fromOutpost as described in #160. Compare the creation and status-change paths, decide how unmapped statuses should behave, and document or implement the selected policy so new issues no longer have an implicit inconsistency.