Add withdrawable fee jettons via JettonWithdrawable

[krebernisak]

Summary

Adds withdrawal of accrued fee jettons to the TON TokenPools via a new shared, stateless handler, JettonWithdrawable (lib/funding/jetton_withdrawable.tolk), mirroring EVM FeeTokenHandler.WithdrawFeeTokens.

This replaces the per-pool manual fee sweep with a generalized, msg-driven flow that all three pool families can share.

Highlights

Shared handler (JettonWithdrawable)

• onWithdraw(msgValue, sender, msg, maxAmount, allowedRecipients) -> coins relays caller-supplied AskToTransfer pairs to the specified jetton wallets.
• Enforces, in a single loop:
  • inbound-value coverage: msgValue >= running sum(transfer.value) + MIN_RESERVE,
  • per-transfer maxAmount bound,
  • optional allowedRecipients allowlist (throws ZeroAddressNotAllowed for zero/none dest regardless), and a no-customPayload guard.
• Each relayed ask is tagged with a WithdrawContext (opcode + initiator) via customPayload, so a bounce is recognized and the initiator is notified with a WithdrawFailed reply (onWithdrawBounced).

Pool wiring

• burn/mint & lockbox: use the base unbounded relay, and onBouncedMessage is extended to discriminate a fee-withdraw AskToTransfer bounce from the existing pool-op asks.
• lock/release (no-lockbox demo): keeps the extra accruedFees ledger. Fees accrue on confirmed lock settle (onLockOrBurnTransferContinueWithFeeSettlement); withdrawals are bounded by the ledger and decrement it by the total actually moved (onWithdrawFeeTokensBounded, maxAmount = st.accruedFees). A bounced withdraw ask re-credits the ledger.
• Adds JettonWithdrawable_Withdraw as a TokenPool_InMessage, dispatched on onInternalMessage to onWithdrawFeeTokensDispatch.

Tests

• Shared TokenPool.withdrawFeeTokens.behavior.ts runs in all three pool specs (LockRelease, BurnMint, Lockbox): accrues-on-lock, withdraw-as-owner, withdraw-as-feeAdmin, reject-non-owner.
• Bounded-ledger overdraw-guard test (lock/release only).
• New bounce-discrimination coverage for the withdraw ask in each family.

Notes

• Auth (owner / fee-admin) is enforced by the caller before invoking the handler; the handler itself only enforces the per-transfer allowlist/limit/value guards.
• Follow-up (see onramp/messages.tolk TODO): migrate the OnRamp's native-TON WithdrawFeeTokens to this shared handler so it can also sweep fee jettons.

[duck-types]

I'm not 100% sold on the opcode manual parsing

[duck-types]

You are potentially allocating an extra cell unecessarily.

Suggested change

	val wrapCell = loadForwardPayloadAsCell(forwardPayload);
	val wrapSlice = loadForwardPayloadAsSlice(forwardPayload);

[duck-types]

Why don't you use builtin decoder?

Suggested change

	var s = wrapCell.beginParse();
	if (s.loadUint(32) != Jetton_ForwardPayloadWrap_OPCODE) {
	return null;
	}
	val UnpackException = 0xff
	try {
	return Jetton_ForwardPayloadWrap.fromCell(wrapCell, UnpackOptions { throwIfOpcodeDoesNotMatch: UnpackException})
	} catch (e) {
	if (e is UnpackException) {
	return null;
	}
	throw e;
	}

Alternativelly, you can use reflect.serializationPrefixOf to get the opcode instead of having a constant

[duck-types]

You can also use a lazy loading + match

[krebernisak]

Sure, polished code here

[duck-types]

Shouldn't this go inside the context, too? It's only used when the message bounces

[krebernisak]

I've put this in the wrap for convenience as in most cases you will at least need the initiator.