Make builder steps unit-testable by abstracting the Oxide client

Problem

All builder steps pull the concrete *oxide.Client out of the state bag and call it directly, so step Run/Cleanup logic (wait loops, timeout handling, cleanup ordering, -force deletion, error propagation) can only be exercised against a live Oxide silo.

Fix

Two viable approaches:

1. Define a narrow interface covering the ~10 client methods the steps actually use (InstanceCreate, InstanceView, InstanceStop, InstanceDelete, DiskDelete, SnapshotCreate, SnapshotDelete, ImageView, ImageCreate, ImageDelete, InstanceExternalIpList, CurrentUserSshKeyCreate, CurrentUserSshKeyDelete) and store that in the state bag instead of the concrete client. Steps get tested with a fake.
2. Alternatively, point the real client at an httptest.Server with canned responses.

Option 1 is less brittle to SDK changes. Unblocks step-level unit tests for the wait/timeout/cleanup paths that acceptance tests can't reliably reach.

Start by locating the builder steps that pull *oxide.Client from the state bag and catalog the listed client methods they use. Choose between a narrow fakeable interface and an httptest.Server, then verify that Run and Cleanup wait, timeout, cleanup-ordering, force-deletion, and error-propagation paths can be exercised without a live silo.