fix: preserve PolicyFlags through serialize/deserialize cycle for permission validator

[bergusman]

Bug: PolicyFlags lost after deserializePermissionAccount

Problem

When serializing a KernelAccount that uses toPermissionValidator with a custom flag (e.g. PolicyFlags.NOT_FOR_VALIDATE_SIG), the flag is not preserved through the serialize/deserialize cycle.

After deserializePermissionAccount, the reconstructed validator uses the default flag value, causing a mismatch in enableSig — which makes the resulting account unable to send UserOps.

Reproduction

const approval = await serializePermissionAccount(
  await createKernelAccount(client, {
    plugins: {
      sudo: ownerValidator,
      regular: await toPermissionValidator(client, {
        // ...
        flag: PolicyFlags.NOT_FOR_VALIDATE_SIG,
      }),
    },
    kernelVersion,
    entryPoint,
  })
);

const account = await deserializePermissionAccount(
  client,
  entryPoint,
  kernelVersion,
  approval
);

// UserOp fails: enableSig mismatch
await account.sendUserOperation({ ... });

Root Cause

serializePermissionAccount does not include the flag field from the permission validator in the serialized payload. Consequently, deserializePermissionAccount reconstructs the validator without it, defaulting to PolicyFlags.FOR_ALL_VALIDATION.

Fix

Include flag in the serialized permission account data and pass it back to toPermissionValidator during deserialization.

Impact

Any flow that relies on not default FOR_ALL_VALIDATION (e.g. session keys used purely for execute without signature validation) is broken when accounts are serialized and shared between server and client.