[Bug] Atomic commits bypass owner-program validator revocation #275

Describe the bug

Atomic CommitFinalize accepts a validator excluded from the owner program's current ProgramConfig.approved_validators, as long as that signer still matches DelegationRecord.authority. The two-phase CommitState path rejects the same signer. Revoking a validator in the program configuration therefore does not stop atomic settlement.

To Reproduce

At DLP commit fb6668c7b5ffd6a89bedee1d13b16402fd0e65de, a local real-SBF ProgramTest used valid delegation state and an initialized owner-program configuration that excluded the signing delegation authority:

1. CommitState returned InvalidWhitelistProgramConfig without changing state.
2. CommitFinalize with the same signer and the next commit ID succeeded, changing account data and decreasing delegated/record lamports by 123,456,789.
3. The excluded validator's fee vault received that amount.

This requires control of the recorded validator authority, not an arbitrary key. The fixture seeded the pre-existing delegation/configuration state; no live network or fee withdrawal was exercised.

Expected behavior

Atomic settlement enforces the same owner-program whitelist policy as CommitState. Apply the check in the shared finalization routine for both inline and buffered atomic instructions, retaining the existing semantics when no program configuration is initialized. A validator-side check alone cannot enforce revocation against a signer that no longer cooperates.

Additional context

The inspected two-phase whitelist check has no equivalent in atomic finalization. The atomic instruction does not accept the program-configuration account. Adding it requires coordinated DLP API/builders and MBV committor changes.

Validator v2.0.0-rc.2 uses atomic inline and buffered instructions, so this is relevant to its normal settlement path. Only inline CommitFinalize was dynamically reproduced; CommitFinalizeFromBuffer shares the unchecked routine but was not separately executed.