Add three btree indexes that back the server-side available-quantity

[EdwinBetanc0urt]

re-validation added to OutBoundOrderLogic.generateLoadOrder as part of the fix for duplicate outbound
orders from the same sales order.

Indexes

• idx_wm_inoutboundline_c_orderline_id on WM_InOutBoundLine (C_OrderLine_ID)
• idx_wm_inoutboundline_dd_orderline_id on WM_InOutBoundLine (DD_OrderLine_ID)
• idx_m_inoutline_wm_inoutboundline_id on M_InOutLine (WM_InOutBoundLine_ID)

Names match the canonical FK-index convention already present in most instances (verified in dyd-dev), so the migration is a no-op there.

Idempotency

All three steps use CREATE INDEX IF NOT EXISTS and provide DROP INDEX IF EXISTS as RollbackStatement. Safe to re-run.

Measured impact (dyd-dev: 61k wm_inoutboundline, 285k m_inoutline)

• With these indexes: 0.43 ms / line (~17 ms for a 41-line generation)
• Without them: ~80 ms / line (~3.3 s for 41 lines)

Test plan

• Migration runs green against a clean instance (indexes created).
• Migration runs green against an instance that already has them (no-op via IF NOT EXISTS).
• pg_indexes shows the three indexes on the expected columns.
• Rollback drops them cleanly.

Notes

CONCURRENTLY is intentionally omitted because migration steps run inside a transaction. On very large production databases, DBAs can pre-create the indexes with CREATE INDEX CONCURRENTLY before running the migration — the IF NOT EXISTS will then make this step a no-op. Same rationale documented in the sibling migration 503650.