bug: `generate --lang <one>` deletes generated output for all other configured languages

[jamon8888]

Summary

Running alef generate --lang <single-language> deletes the previously-generated
output for every other configured language, not just the language(s) excluded
by the filter. alef generate run without --lang does not exhibit this problem.

Environment

• alef version: 0.30.17
• OS: Windows 10 (native, not WSL)
• Consumer repo: jamon8888/xberg (private fork of xberg-io/xberg-style layout)
• alef.toml [workspace] languages (15 configured):
  python, node, ruby, php, ffi, go, java, csharp, elixir, wasm, dart, jni, kotlin_android, swift, zig

Exact command

alef generate --lang wasm

Observed behavior

The command removes hundreds to thousands of previously-generated files belonging
to the other configured languages (ruby, swift, zig, python, php,
java, csharp, kotlin_android, etc.) even though only wasm was requested.
Only the wasm binding output is (re)generated; everything else configured in
[[crates]] / [crates.<language>] is left deleted rather than regenerated or
left untouched.

Expected behavior

alef generate --lang wasm should only touch generated output that belongs to
the wasm target. Output for languages not named in --lang should be left
exactly as it was on disk (neither regenerated nor deleted).

Scope / reproducibility

• Reproduced twice, in two independent git worktrees of the same repo:
  once on a feature branch (feature/wasm-engine) and once on main.
• Both times the working tree was clean before running the command, so the
  deletions were unambiguously caused by the alef generate --lang wasm
  invocation itself (confirmed via git status/git diff --stat showing mass
  deletions across every non-wasm language's generated paths immediately after
  the command, recoverable only via git checkout/git restore since the repo
  is git-tracked).
• alef generate (no --lang filter) does not reproduce the problem —
  only the filtered form does.

Suspected area

Likely a pruning/cleanup step in the generate command that computes "stale
generated files to remove" without scoping that computation to the
--lang filter — i.e. the filter is applied to what gets (re)written but
not to what gets considered for deletion, so it treats the unfiltered
languages' generated files as orphaned/stale and removes them.

Impact

Any consumer who uses --lang <x> to iterate quickly on a single binding
target (exactly the workflow recommended for narrow iteration) risks silently
losing generated output for all other bindings. In a git-tracked repo this is
recoverable via VCS, but it's easy to not notice until a diff review, and in a
worktree/CI context without a clean baseline it could be a real data-loss bug.

Workaround

Avoid --lang when other languages' generated output must be preserved; run
unfiltered alef generate instead, or regenerate all languages afterward via
alef generate --clean --format before committing.