test(conformance): verify Snap installation status in Ubuntu VM

[elezar]

Summary

Add a VM-based Ubuntu Snap installation check to the conformance workflow. It mirrors the Snap release canary through gateway registration and openshell status, without creating a sandbox.

Related Issue

No issue required: CI packaging coverage and workflow reuse.

Changes

• Add Ubuntu test-guest provisioning for snapd, Docker Snap, and candidate OpenShell Snap installation.
• Build a branch Snap and verify its installed gateway reaches openshell status.
• Extract a reusable single-architecture Snap build workflow and use it from release packaging.

Testing

• mise run pre-commit passes
• Local Ubuntu VM installation/status flow passes with a candidate Snap
• Unit tests added/updated (not applicable)
• E2E tests added/updated (not applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-3182.docs.buildwithfern.com/openshell

[elezar]

@olivercalder I was iterating on this, and it was impossible to get the package installed and connected without this change. Since the gateway service is installed in a started state, it crash loops because it can't discover a valid compute driver. At the point where the sudo snap connect openshell:docker docker:docker-daemon tries to restart the gateway in the connect-plug-docker hook, the restart is rejected because (as Codex proposes) some restart limit has been reached.

The argument of switching to install-mode: disable is then that the service will be started (and enabled) at the point where the docker plug is connected -- either automatically for installations from the Snap store directly, or manually in the case of testing.

I'm not quite certain why the existing canary infrastructure allows things to pass, but it could be that the VM-based tooling that we have now adds some other delay which allows the gateway to restart more often.