Handle empty code objects consistently across workloads

[luke-lombardi]

Dockerfile and registry services can reuse the canonical empty object registered by a VM, which has no uploaded archive. The worker only handled that object locally for sandboxes and VMs, so services failed during mount setup with S3 NoSuchKey.

Use the existing empty-workspace path whenever the object has the canonical empty hash. This is a one-line runtime change; missing nonempty objects still fail.

Validation: the expanded regression test fails for services before the fix and passes afterward. Mount/cache tests and abstraction common tests pass. The full worker suite has one unrelated macOS failure in TestCheckpointHostProfileIgnoresWorkerRelease, which expects a Linux CPU profile.

---

Summary by cubic

Fixes services that reference the canonical empty code object from failing during mount setup with S3 NoSuchKey. The worker previously applied the local empty-workspace path only to sandboxes and VMs, even though Dockerfile, registry, and other workloads share the same empty object, which has no uploaded archive.

• The empty-object check now runs for all stub types; missing nonempty objects still fail as before.
• Regression tests cover every stub type and verify the missing-object failure path.

^{Written for commit 183a68b. Summary will update on new commits.}

[jackf-beamcloud]

Looks right. The hash is the sha256 of an empty zip, so any object that matches it would extract to an empty workspace anyway. That makes creating the workspace locally safe for every stub type, and a missing object with any other hash still fails as before. Non-blocking: the doc comment on GetOrCreateEmptyStubObject still says only sandbox workers recognize the hash.