moon workspace mode ignores per-member preferred-target for `moon build --target js`

[dowdiness]

Summary

When a package with `preferred-target: js` is a member of `moon.work`, `moon build --target js` from inside that package emits only wasm-gc artifacts. The expected JS bundle is never produced.

Affects `examples/canvas` and `examples/ideal` after PR #333 added them as workspace members.

Reproduction

```bash
cd examples/canvas # preferred-target: js, member of moon.work
moon build --target js --release
find _build -name 'main.js' # → empty
ls _build # → wasm-gc/ (only)

With workspace disabled:

MOON_WORK=off moon build --target js --release
find _build -name 'main.js' # → _build/js/release/build/main/main.js ✓
```

Apparent expectation vs. observed

The MoonBit v0.9.2 release notes say:

Per-member preferred-target: Workspace builds (`moon build`, `moon test`) now respect each member's declared `preferred-target`, so mixed frontend/backend projects can build in a single command.

In our setup that doesn't happen. Workspace context overrides the member's `preferred-target: js` and the build targets wasm-gc.

Environment

• moon `0.1.20260522` (84aa893)
• moonc `v0.9.3+3d4544a9e`
• Linux WSL2

Workaround in canopy

PR #333 sets `MOON_WORK=off` for the vite-time builds:

• `scripts/test-canvas-e2e.sh`
• `.github/workflows/benchmark.yml` (editor-response-benchmark job)

This is a temporary workaround; the underlying `moon` behavior should match its release-note promise.

Followup

• Decide whether to file upstream at `moonbitlang/moon` once we've confirmed the minimal repro outside canopy.

Tracking artifact for

• `scripts/test-canvas-e2e.sh:25-30` — `MOON_WORK=off` comment
• `.github/workflows/benchmark.yml:189-194` — same