feat: support SOCI snapshotter's lazy loading mode

[m1so]

Trying to pull a SOCI manifest / image lazily current results in an error as /dev/fuse is not mounted.

See soci-snapshotter codebase and the following error logs:

{"binary":"fusermount","error":"exec: \"fusermount\": executable file not found in $PATH","key":"k8s.io/106/extract-876213091-quzh sha256:...","level":"info","mountpoint":"/var/lib/containerd/io.containerd.snapshotter.v1.soci/snapshotter/snapshots/72/fs","msg":"fusermount binary not installed; trying direct mount","parent":"sha256:...","time":"2026-01-25T14:38:24.154801378Z"}

{"error":"no such file or directory","key":"k8s.io/106/extract-876213091-quzh sha256:...","level":"error","mountpoint":"/var/lib/containerd/io.containerd.snapshotter.v1.soci/snapshotter/snapshots/72/fs","msg":"failed to make filesystem server","parent":"sha256:...","time":"2026-01-25T14:38:24.154882399Z"}

{"error":"no such file or directory","key":"k8s.io/106/extract-876213091-quzh sha256:...","level":"warning","msg":"failed to prepare remote snapshot","parent":"sha256:...","remote-snapshot-prepared":"false","time":"2026-01-25T14:38:24.154897739Z"}

I am using custom configuration for SOCI in Talos machine config:

apiVersion: v1alpha1
kind: ExtensionServiceConfig
name: soci-snapshotter
configFiles:
  - mountPath: /etc/soci-snapshotter-grpc/config.toml  # replace default config shipped with extension
    content: |-
      [cri_keychain]
        enable_keychain = true
        image_service_path = "/var/run/containerd/containerd.sock"

      [pull_modes]
        [pull_modes.soci_v1]
          enable = true
        [pull_modes.soci_v2]
          enable = true

although the default SOCI configuration from this repo fails as well (as soci_v2 is the default), leading me to believe this extension never worked properly when using lazy pull mode. It might have worked when using parallel pull mode but I haven't tested myself.

Note that the additions were adopted from estargz extension, which provides similar functionality.

There is also an issue where fusermount3 from fuse extension is not correctly discovered by SOCI (as they only check for presence of fusermount), but I believe it's not blocking as there is a fallback and the issue can be fixed upstream (to match estargz behaviour) or fuse extension could also symlink fusermount3 to fusermount, please let me know whether you'd also accept this contribution or whether I should submit a patch for SOCI. Thanks!
cc @frezbo & @smira

[m1so]

Hi @frezbo, could you please have a look whenever you're available? 🙏

Would be great if the fix could make it to a future v1.12.x release