E2E test improvements

We have a single e2e test today, which spins up a kind management cluster and a minimal workload cluster. We may want to test more scenarios: do we successfully reattach the control plane's floating IP if the attached control plane instance vanishes? Do we adopt the floating IP if it already exists? And so on. We should also discuss which tests belong as e2e tests on a real oxide cluster, which as unit tests, and which as integration tests with a stubbed k8s and oxide client.

We should also e2e test a simple workload on the workload cluster, because I have a suspicion that the current e2e test cluster actually won't produce a working network overlay; I'll file a separate issue about this.

Finally, we should consider running the e2e tests on ci, since they're only run on developer machines today.

Start by locating the existing single end-to-end test that creates the kind management and workload clusters, then review how the repository separates end-to-end, unit, and integration tests. Define coverage for floating-IP recovery, existing-IP adoption, and a simple workload, and determine how these tests should run in CI; done means the selected scenarios and test placement are implemented.