AllocateMiningJobToken.Success spec says the following:

The following rules apply to AllocateMiningJobToken.Success.coinbase_tx_outputs:

• JDS MUST reserve the first output with a locking script where the pool payout will go. While this output is initally set with a 0 amount of sats, this convention designates this locking script as the pool payout output.
• JDS MAY add more 0 value outputs in addition to the pool payout output.

Once JDC receives AllocateMiningJobToken.Success, the following rules apply to the subsequent DeclareMiningJob.coinbase_tx_suffix (if under Full-Template mode) and SetCustomMiningJob.coinbase_tx_outputs (under both Full-Template and Coinbase-only modes) message fields:

• JDC MUST allocate sats into the pool payout output in order to qualify for pooled mining rewards. JDS and Pool SHOULD reject custom jobs that fail to do so.
• JDC MAY add more 0 value outputs in addition to the ones established by JDS.
• JDC MAY add more non-0 value outputs in addition to the ones established by JDS. In doing so, the template revenue is not fully allocated to the designated pool payout output, so Pool MAY pay proportionally smaller rewards for this job.
• JDC MAY arbitrarily reorder the outputs to something different from the original ordering of AllocateMiningJobToken.Success.coinbase_tx_outputs.
• Under Full-Template mode, the order of the outputs under DeclareMiningJob.coinbase_tx_suffix and SetCustomMiningJob.coinbase_tx_outputs MUST remain the same, even if they differ from the original AllocateMiningJobToken.Success.coinbase_tx_outputs.

In summary, the pool payout goes to one single output (standardized as the first output of AllocateMiningJobToken.Success.coinbase_tx_outputs), and JDC is free to add more outputs and shuffle them under any arbitrary ordering scheme.

#24 was a naive implementation with this regard, mainly because SRI Pool does not provide real payouts, so I originally regarded this as a low-priority feature

so JDS never validates whether the coinbase tx in DeclareMiningJob (and the matching SetCustomMiningJob) has the correct outputs with the pool payout

but in the spirit of trying to shape jd_server_sv2 as a reusable library, this should be implemented

more specifically:
jd_server_sv2::job_declarator::job_validation::bitcoin_core_ipc::BitcoinCoreIPCEngine::handle_declare_mining_job must check that DeclareMiningJob contains at least one output that abides by the following criteria:

• locking script matches pool payout
• non-zero amount

since JDC MAY allocate part of the total template revenue to outputs that are not pool payout, struct DeclaredCustomJob must keep track of:

• total coinbase amount
• pool payout amount relative to total coinbase amount

this will help Pools pay proportionally (akin to DMND SLICE)

later on, jd_server_sv2::job_declarator::job_validation::bitcoin_core_ipc::BitcoinCoreIPCEngine::handle_set_custom_mining_job already makes sure the coinbase tx in SetCustomMiningJob is identical to the corresponding DeclareMiningJob, so nothing needs to be done there