Plan in Jira

Motir-AI creates and updates issues directly in a connected Jira project from a Motir plan, mirrors them as motir-core work items, and keeps the two in sync.

This story owns the shared WRITE-BACK ENGINE — it is the foundation every other vendor story in this epic fans off (they are each blocked_by it and add only their own vendor adapter). The engine, delivered here and exercised end-to-end through Jira:

• Plan → vendor mapping — the inverse of the importer's SourceIssue normalisation (7.16.4a — connector interface + normalised SourceIssue): Motir kind / type / status / priority / assignee / labels / parent-child and dependency edges out to the vendor's own field model, with the same per-connection mapping the import wizard already captures.
• The mirror map + idempotency — extend the external-id ↔ work-item map from 7.16.3 — the Import model + idempotency so a re-push updates the item it already created instead of duplicating it.
• Push + update — create on first push, patch on change, with per-item failure isolation (one rejected field must not abandon the rest of the plan) and the vendor's rate limits respected.
• Sync back — a webhook receiver so vendor-side edits land on the motir-core copy, plus the conflict rule when both sides changed.
• The connect step — request write scope on the existing Jira OAuth app at authorize time (7.16.11 — Jira OAuth 2.0 (3LO) connect flow shipped the read-scoped flow; scope is per-authorization, not baked into the app) and enable the app's webhook toggle.

Verified preconditions. Jira is already a live connected source: the OAuth 3LO connect flow, the encrypted token store (7.16.10 — ImportSourceIdentity), and the Jira API client (7.16.4 — Jira + Linear connectors) all shipped done. This story reuses all three; it registers no new OAuth app.

Boundary. WRITE direction only — the read/import path stays with Issue importer in Epic 7. The engine built here is vendor-agnostic by contract but is only proven against Jira in this story; each later vendor story supplies its own adapter + connect flow against it and must not re-implement the mapping, mirror map, or sync loop. Non-Jira vendors are out of scope here.

Not yet expanded into subtasks — expand when picked up.