fix(#186): evsieve build box retries with fuse-overlayfs on overlay-mount failure

[aradanmn]

Closes #186.

Problem

Found on the Deck during #122 hardware validation, on two separate installs
right after --purge wiped the podman/distrobox store:

```
Preparing mcss-evsieve-build box (first run pulls a debian image) (4s)
evsieve build box could not be created; seamless controller reconnect
unavailable (v1.2 proxy feature stays OFF); your v1.1 install is unaffected.
```

Fails in ~4s — a real error, not a timeout. Fail-open worked exactly as
designed (v1.2 proxy off, v1.1 unaffected, install completes), but seamless
reconnect (#38) silently stops being available on this Deck.

Root cause

Reproduced directly, outside any of our scripts:

```
$ distrobox create --yes --name diag --image debian:12
Error: creating container storage: creating an ID-mapped copy of layer
"...": creating overlay mount to .../merged, mount_data="...userxattr":
invalid argument
```

Podman's native (kernel) overlay driver rejects an ID-mapped mount on this
Deck's kernel (6.16.12-valve24.5-1-neptune). fuse-overlayfs sidesteps
the kernel driver entirely and is already shipped on the Deck — verified
fix, end to end on real hardware:

```
$ distrobox create --yes --name diag --image debian:12
--additional-flags "--storage-opt overlay.mount_program=/usr/bin/fuse-overlayfs"
(create: exit 0; enter: exit 0)
```

Fix

`_evsieve_create_box()` is the one new encoding, called from both places
`_evsieve_ensure_box()` creates a box (the initial create AND the
heal-after-broken-box retry): try the plain form first, and only on
failure — with fuse-overlayfs actually present — retry once with the
storage-opt via distrobox's --additional-flags passthrough.

A host where the native driver already works sees zero behavior change:
no extra flag, no risk of a fuse-overlayfs-specific quirk on a host that
never needed one.

Tests

`tests/test_evsieve_management.sh`: 11→14, with a distrobox stub that fails
unless its create call carries the exact expected storage-opt value:

• T12 — a healthy host (plain create succeeds) never even checks for
  fuse-overlayfs, let alone attempts the fallback
• T13 — plain fails, fuse-overlayfs absent → degrades exactly as before
  (one attempt, clean failure, no retry loop)
• T14 — plain fails, fuse-overlayfs present → the fallback retry
  succeeds

Mutation-tested, five mutations. Four caught immediately; one (a typo'd
fuse-overlayfs path) initially slipped past because the first test stub
matched any substring containing "fuse-overlayfs" — a typo'd value still
contains that substring. Tightened the stub to an exact last-argument match;
all five caught after.

No CI baseline change — test_evsieve_management.sh has no dedicated CI
gate entry (verified against ci.yml), consistent with the other
network/toolchain-dependent module suites.

Not done

Not yet re-validated on the Deck with this exact fix (the original bug was
found and diagnosed live during #122; this is the permanent fix, verified
manually against real distrobox/podman but not yet through the full
install_evsieve() pipeline on hardware). Will batch into the same Deck
sitting as #184/#185.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dru6wVc2ZcjiTpa6p7yJDh