Fresh resolves filtered optional native deps by the host's os/cpu/libc
before writing the lockfile, so an `aube install` on macOS produced an
`aube-lock.yaml` missing `@rollup/rollup-linux-*`, `@esbuild/linux-*`,
etc. A subsequent install on Linux CI then failed because the linker
had no entry to reach for. Users had to hand-write
`pnpm.supportedArchitectures` in `package.json` just to get a
portable lockfile (see e.g. jdx/usage#594).

The fix: when the project writes `aube-lock.yaml` and the manifest
has no explicit `supportedArchitectures`, resolve across an explicit
set of (os, cpu, libc) triples — darwin-arm64, linux × {x64, arm64} ×
{glibc, musl}, and win32 × {x64, arm64}. darwin-x64 is intentionally
out of the baseline: Apple Silicon is the shipping Mac platform and
several major native ecosystems (sharp, swc) have already dropped
Intel Mac binaries. A user still on an Intel Mac widens with
`pnpm.supportedArchitectures.cpu: ["current", "x64"]` as usual.

`node_modules` stays host-only: the in-memory graph is trimmed via
`filter_graph` after the lockfile write, mirroring the pass that
already runs on the lockfile-happy install branch.

Foreign lockfile formats (pnpm-lock.yaml, yarn.lock,
package-lock.json, bun.lock) keep their current host-only default so
aube doesn't silently bake more packages into them than the native
tool would have produced.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The prior revision mapped `source_kind_before` directly into
`ResolverConfigInputs::target_lockfile_kind`, so `None` meant both
"no lockfile on disk — we'll write aube-lock.yaml" and "lockfile=false
— we'll write nothing." `configure_resolver` then widened the
platform filter in the second case too, and the streaming fetch
coordinator downloaded optional tarballs for every common platform
just for the in-memory graph trim to discard them before linking.

Collapse the `lockfile=false` case to `None` and reserve `Some(Aube)`
for the "will actually write aube-lock.yaml" intent. The wide-default
branch now keys off a strict `Some(Aube)` match, so nothing resolves
packages that no sink would consume.

Caught by Cursor Bugbot on #94.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two follow-ups on the aube-lock widening, both caught by Cursor
Bugbot on #94:

(1) `aube_lock_default()` listed a hand-picked matrix that deliberately
omitted darwin-x64. Applied verbatim, that dropped Intel Mac users'
own native optional deps out of the resolver's graph — the
post-resolve `filter_graph` can't bring packages back that never
entered the graph. Always append the host's own triple to the
baseline matrix so an Intel Mac (or freebsd, ppc64, …) install gets
its own natives even when the user hasn't hand-rolled
`supportedArchitectures`.

(2) The streaming fetch coordinator downloaded tarballs for every
resolved package, so widening the resolver for aube-lock.yaml also
pulled every foreign-platform native tarball into the store only for
`filter_graph` to discard the graph entries before link. Carry
`os`/`cpu`/`libc` on `ResolvedPackage` and check each incoming
package against the same narrow (manifest) supportedArchitectures
the post-resolve filter uses — if the linker would drop it, skip the
fetch. Registry ignoredOptionalDependencies get the same treatment.
Local `file:`/`link:` packages have empty arrays and always pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… optionals

The previous commit skipped tarball fetches for packages that failed
the host `is_supported` check or were named in
`ignoredOptionalDependencies`. That's correct for optional deps but
unsafe in general: `filter_graph` only strips optional edges, so a
required dep with platform constraints (broken package, or one that
declares `os`/`cpu` without the `optional` marker) survives the graph
trim — and would then crash at link time when the store index is
missing because we skipped the fetch.

Revert the fetch filter. The ResolvedPackage struct goes back to its
pre-widening shape — nothing external consumed the os/cpu/libc
fields, so keeping them would be dead API surface. We accept
over-fetching foreign-platform natives into the CAS when aube-lock
widening is active (first resolve after package.json changes); the
extra tarballs land in `~/.aube-store` but never get linked into
`node_modules` — over-fetch, not over-link.

Caught by Cursor Bugbot on #94.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>