strukto-ai/mirage `Workspace.execute` command execution

## Summary

`Workspace.execute(command, { signal })` documents an `AbortSignal` option, but the signal is only checked once at the very start of the call. Aborts that fire after `execute()` begins are ignored — long-running commands run to completion regardless.

## Repro

```ts
import { Workspace, RAMResource, MountMode } from '@struktoai/mirage-node';

const ws = new Workspace({ '/data': new RAMResource() }, { mode: MountMode.WRITE });

// Pre-aborted signal: works as expected — throws AbortError.
const ac1 = new AbortController();
ac1.abort();
try {
await ws.execute('echo hi', { signal: ac1.signal });
} catch (e) {
console.log(e.name, '-', e.message);
// Output: AbortError - execute aborted
}

// Mid-flight abort: silently ignored.
const ac2 = AbortSignal.timeout(50);
const t0 = Date.now();
const r = await ws.execute('sleep 5', { signal: ac2 });
console.log('took', Date.now() - t0, 'ms; exit:', r.exitCode);
// Output: took ~5000 ms; exit: 0
// Expected: AbortError thrown after ~50 ms.
```

## Where in the source

`workspace.ts`'s `execute()` (around line 530) checks `options.signal?.aborted === true` once at entry and throws if so. There's no `signal.addEventListener('abort', ...)` registration and no cooperative `signal.aborted` polling between commands in a list, between pipeline stages, between iterations of `for`/`while`/`until` loops, or between dispatch boundaries.

The `JobTable` already has its own per-job `AbortController` infrastructure (used internally for...