Include the canonical bump in the order PDA

[kaze-cow]

Description

Include the order's own canonical bump in the order PDA. This allows for the bump parameter to be removed from ReclaimOrder and BeginSettle.

Motivation

• Overall reduces the complexity of BeginSettle's input, the most complicated instruction in the program at this time
• Improves IDL compatibility by removing a "parallel array". There is still more that would have to be done here
• Seems to be more in line with how most modern solana programs handle the problem of bump rederivation.

CU impact

Measured with the CU benchmarking helper added on this branch, which reads the settlement program's own compute cost out of the transaction log trace (CPI to SPL Token excluded) and writes it to target/cu-report.json. Baseline is 03545e4, the commit directly before the functional change, so the only difference is the bump move — the test addresses and the benchmark helper are already pinned in both.

Measurement	Before	After	Δ
create_order	3391	3418	+27
reclaim_order	2138	2135	−3
settle, 1 order, no pulls	12165	12148	−17
settle, 2 orders, 1 pull each	19399	19376	−23
settle, 3 orders, no pulls	22345	22324	−21

The settle rows are the whole [BeginSettle, FinalizeSettle] transaction, because BeginSettle is never submitted alone; FinalizeSettle is untouched by this PR, so the delta is BeginSettle's.

Reproduce with:

just build-program
cargo test --test create_order --test reclaim_order --test begin_settle_orders
cat target/cu-report.json

Out of Scope

The original ticket said to move all storage, but it seems it is most valuable to include only for the order pda at this time. This is because for the other two current PDA types:

• Buffer accounts are actual token account PDAs, so we can't control the storage inside of them/add a bump. We can add another PR to always rederive the PDA instead if we still want to remove the PDA as a parameter.
• the single state pda is currently rederived every time it is loaded rather than accepting as an input. Considering that this change would look/shape much differently from the Order PDA changes, it should be included in a separate PR

How to test

This is mostly refactoring, so most of the tests should work the same as before the change. Confirm the overall methodology

[linear-code]

SC-257

[fedgiac]

The design looks good, I think it's close to merging.

Some notes on the scope (the current one is ok, this is future code):

Buffer accounts are actual token account PDAs, so we can't control the storage inside of them/add a bump. We can add another PR to always rederive the PDA instead if we still want to remove the PDA as a parameter.

We can test this, but I expect this to be overall more expensive (and non-deterministically so), so I fear we're going to keep it.

the single state pda is currently rederived every time it is loaded rather than accepting as an input. Considering that this change would look/shape much differently from the Order PDA changes, it should be included in a separate PR

Completely agree. The security angle is a bit trickier there imho.

[fedgiac]

Looks good!