Issue Invoice

Turn one draft into a transmitted e-invoice (AP-031's issue transaction).

The whole of it — number, XML, XSD validation, transmission — happens in the store, in that order and for reasons documented there. This route's own job is the status code, and the mapping is the ticket's acceptance criteria:

• 404 — no invoice of that id for this caller. Unknown and somebody else's stay indistinguishable, as everywhere else here;
• 409 — the id names a real invoice of theirs that is not a draft, which is what a second issue call for the same document produces. Issuing is therefore idempotent in the only sense a fiscal sequence allows: the repeat is refused rather than absorbed, and no second number is spent;
• 422 — the draft is incomplete, or the profile/customer cannot produce a valid document. The store's message names every missing field at once and nothing has been written, so the fix is one edit and one retry;
• 503 — two numbering attempts lost a race. Transient by construction;
• 502 — the transmission seam failed. Where it left a numbered document behind, that document sits in error awaiting a retry; either way the failure is upstream rather than in the request, which a 500 would deny.

Carries the AP-099 write limiter: it is the most expensive mutation on the router (a build, an XSD validation and an outbound call), and the only one that consumes a number.