Accept the wallet's Lighthouse guard instructions on sponsored placement

[squadgazzz]

Description

#4958 let the wallet's compute-budget instructions through, which unblocked MetaMask. Phantom also wraps the bundle in Lighthouse guard instructions, so it still fails, and in the same two places: an assertion after CreateOrder misses split_last, and the assertions in front land in the preparations where the template rejects the program.

Decoding the transaction Denis reported, all four are assertions, AssertAccountInfoMulti three times and AssertTokenAccountMulti once. One of them covers the funder, so Phantom is guarding the fee payer rather than spending it. Assertions read account state and abort the transaction on a mismatch, so they cannot move funds and can sit outside the template like the compute budget.

MemoryWrite and MemoryClose stay rejected. Both name a payer that funds the memory account's rent, and on a sponsored creation that payer can be the funder.

Changes

• Lighthouse instructions are set aside before the sponsored template is matched, so they may appear anywhere
• Its two memory instructions are refused

How to test

Updated integration tests. The end-to-end placement test now sends Phantom's shape, guards before and after, and fails without this change.

[claude]

Claude finished @squadgazzz's task in 2m 57s —— View job

---

Review

• Read the diff and surrounding code
• Analyze correctness & edge cases
• Post inline findings
• Post summary

The change is sound and the reasoning in the description holds up: pulling Lighthouse instructions out of the bundle (like compute-budget) before split_last runs fixes both the missed-split_last and template-rejection failures, and the assertions are read-only so they're safe to sit anywhere. Rejecting MemoryWrite/MemoryClose is the right conservative call given they name a rent payer that can be the funder. Tests cover both directions (memory rejected, assertions before+after accepted).

One non-blocking point left inline: check_lighthouse is a denylist (reject 0/1, accept the rest). Since the safe set is exactly the Assert* variants and Lighthouse is upgradeable at a fixed address, an allowlist of known assertion discriminators would be strictly safer for a fund-guarding path. Correct against today's program either way.

Nit (not worth a change): empty-data Lighthouse instructions fall into the _ => Ok arm and are accepted, but they can't execute on chain, so no impact.

I couldn't run cargo check/tests in this environment (command not permitted), so I reviewed by reading only.
· solana-orderbook/allow-lighthouse-guards