fix: bump gas price multiplier and make it configurable

[livingrockrises]

to prevent bundler fee rejections

Problem

Bundlers enforce a minimum maxFeePerGas at submission time based on current network conditions. Because base fee can tick up between when estimateFeesPerGas runs (inside prepareUserOperation) and when eth_sendUserOperation is actually called, a hardcoded low multiplier leaves no room for that drift — producing rejections.

Changes

• getGasFeeValues.ts — add GasPriceMultipliers type; accept optional multipliers param; default maxFeePerGas 1.3 → 1.5, default maxPriorityFeePerGas 1.0 → 1.1
• createSCSBundlerClient.ts — expose gasPriceMultipliers in config; thread it through to getGasFeeValues
• decorators/bundler/index.ts — re-export GasPriceMultipliers type

Usage

gasPriceMultipliers is set once at client creation — every sendUserOperation / sendTransaction that flows through that client automatically gets buffered fees with no per-call changes needed.

// defaults (1.5× / 1.1×) apply automatically — no change needed
const client = createSmartAccountClient({ ... })

// custom — tighten or loosen per deployment

const client = createSmartAccountClient({
  account: await toStartaleSmartAccount({ ... }),
  transport: http(bundlerUrl),
  client: publicClient,
  paymaster: scsPaymasterClient,
  paymasterContext: scsContext,
  gasPriceMultipliers: { maxFeePerGas: 1.2, maxPriorityFeePerGas: 1.05 },
})

// call sites are unchanged
const hash = await smartAccountClient.sendUserOperation({ calls: [...] })

If maxFeePerGas and maxPriorityFeePerGas are both supplied explicitly on the sendUserOperation call, viem short-circuits fee estimation entirely and the multiplier is not applied — the provided values are used verbatim:

// multiplier is bypassed — values go through as-is

  const hash = await smartAccountClient.sendUserOperation({
    calls: [{ to: "0x2cf4...", value: 0n, data: "0x" }],
    maxFeePerGas: BigInt(8089190),
    maxPriorityFeePerGas: BigInt(8089190),
  })