fix(sandbox): load @deno/sandbox lazily

[piscisaureus]

deno deploy executes this package with the user's workspace config
applied (the subcommand disables the lockfile and node_modules, but not
config discovery), so the CLI's static import of @deno/sandbox made
Deno consider a workspace member named @deno/sandbox for the CLI's own
module graph. Inside such a workspace (e.g. the sandbox repo itself)
every command either emitted

Warning Workspace member '@deno/sandbox@x.y.z' was not used because
it did not match '@deno/sandbox@^...'

or, when the member's version satisfied the constraint, linked the
local package into the CLI and crashed it outright (reproduced:
"does not provide an export named 'Client'").

• import @deno/sandbox only via a dynamic import in sandbox/api.ts,
  executed when a sandbox command actually runs; value uses in
  create/connect/volumes/snapshot go through it
• remaining references are import type, which is erased at runtime
  and never resolved by the module loader
• adds a regression test asserting no first-party module has a static
  code edge to @deno/sandbox (via deno info --json)

Non-sandbox commands now run with zero @deno/sandbox resolution, so
neither the warning nor the linking can occur for them. The sandbox
subcommands still resolve it at run time; full isolation needs the
deno subcommand to disable config discovery for the jsr-fetched CLI.