fix(payments): orchestrate a payment automatically after it is initiated

[tiana-code]

fix(payments) #317 - orchestrate a payment automatically after initiate.

The defect

PaymentOrchestrator.process() (INITIATED -> SCREENING -> bank submit -> SUBMITTED) had NO production caller - only the retry path used the orchestrator, and only for payments already in SCREENING (its scheduler is off by default). So a payment created via POST /v1/payments stayed in INITIATED forever. Found during #236 scoping by source verification; the e2e demo (#236) is precisely the test that would have caught it.

Fix

• Publish PaymentInitiatedEvent inside createPayment (within the reserveOrRun transaction; invariant noted in a comment).
• PaymentOrchestrationTrigger: @async + @TransactionalEventListener(AFTER_COMMIT) -> orchestrator.process(id), so screening and the external bank call run off the request thread, after the row is durably committed, never inside a transaction (CLAUDE.md 8.10). A BankProviderException leaves the payment in SCREENING for the existing retry; the listener catches and logs so the async worker survives.
• PaymentAsyncConfig: @EnableAsync + a bounded ThreadPoolTaskExecutor (core 2 / max 8 / queue 100) that drains on graceful shutdown.
• Idempotent replay returns the existing payment without re-publishing, so it does not re-trigger. A second process() is a safe no-op (the state machine rejects the transition).

Tests

Unit: the trigger processes on the event and swallows a failure; the service publishes the event on initiate. The full after-commit -> async -> SUBMITTED path is exercised by the #236 compose-smoke demo on a live stack (a JVM @DataJpaTest slice cannot load the async listener). detekt + spotless + unit tests green locally; integrationTest runs on CI.

Gate chain

critic: GO-WITH-CHANGES. code-reviewer + security-auditor reviewed. Applied: bounded @async executor (was the HIGH), invariant comment. Verified: process() is non-transactional by design (each transition is its own short tx). Durability backstop (the retry sweeper should also recover stuck INITIATED, not only SCREENING) tracked as follow-up #318; the bounded executor's graceful drain already covers the shutdown case, leaving only a hard-crash window. evaluator: PASS (0.85).

Closes #317