ci: live-ZFS + Trident-on-k3s acceptance gate (scheduled)

[hartsock]

Context

.github/workflows/ci.yml's header documents a set of "aggressive supersets
(deep-regression, cross-os, security-audit, live-zfs, release) [that] live in
their own scheduled workflows" — but only ci.yml and release.yml exist. The
live-zfs / Trident-on-k3s acceptance gate for the already-shipped ZFS +
control-plane path is not implemented, so the "an unmodified Trident/CSI driver
drives the full workflow" claim is unverified in CI.

Per-protocol acceptance gates exist for the new work (#59 NFSv4.1, #65 CIFS),
but there is no live gate for the shipped v0.3.x ZFS / NFSv3 base.

Scope

• A scheduled (and manually dispatchable) workflow that stands up nessie-store
  against a real ZFS pool and exercises the control plane end to end
  (volume / snapshot / FlexClone) over the ONTAP REST surface.
• Drive it with an unmodified ONTAP client (netapp-ontap SDK / Ansible
  netapp.ontap) to prove the "plug in unmodified" claim.
• Trident-on-k3s: provision a volume via the CSI driver against nessie-store,
  mount it over the embedded NFSv3 data plane, then read/write/snapshot/clone.
• Marked live / root-only; the hermetic per-PR gate is unaffected.
• Once the SnapMirror data plane lands, extend this gate with a two-instance
  replication check.

Acceptance

• A green scheduled live-zfs + Trident-on-k3s run on the self-hosted runner; the
  per-PR ci.yml gate is unchanged.

Sequencing

Base-first: verify the shipped base before widening the protocol surface. Pairs
with the SnapMirror data-plane issue.