…every coexisting copy, contain config-sourced roots

Post-merge audit follow-up on #218 (gem crawler flat-BUNDLE_PATH
discovery), mirroring the #216 npm multi-copy precedent (0433bcb).

1. MULTI-COPY (most severe): bundler's scoped `<engine>/<abi>/gems`
   and flat `gems/` stores coexist under one root, each holding a REAL
   physical copy of the same gem@version — exactly the state #218's
   tests create. First-wins merging resolved the purl to ONE path, so
   apply patched one store and reported success while the other
   bundler loaded pristine (vulnerable) bytes. Fix mirrors #216:
   `find_all_packages_for_purls` now routes the release-variant
   ecosystems through an accumulating `merge_variant_copies` (reusing
   `push_path`, base-PURL keyed, precedence order kept) and apply's
   variant branch fans out per copy for gem — per-copy Applied events,
   `summary.applied` counts each copy, a copy matching no variant
   fails loudly. Rollback already carried every copy via
   `merge_qualified` and its per-path grouping; the new in-process
   suite pins both directions. PyPI/Maven deliberately keep the
   one-representative contract (the nuget `already_patched`
   double-patch regression from #216's second commit), as do all
   collapsing consumers (vendor/vex/setup/get/repair-vendor).
   scan --sync patches every copy too (it runs the real nested apply);
   scan's inventory stays purl-level, byte-identical to npm's
   crawl_all purl-dedup precedent.

2. PRECEDENCE: roots probed local-config > env > default vendor/bundle
   (bundler's real precedence; the old order was inverted), so
   first-representative consumers pick the copy bundler actually loads.

3. REGRESSION vs pre-#218: env/config roots no longer trip the
   `gem env` fallback early-return — only the historic project-local
   vendor/bundle probe keeps it. Default gems (rexml/json) live only
   in the DEFAULT/system gem homes, so an env-BUNDLE_PATH project gets
   those homes appended (deduped) again.

4. SECURITY: a config-sourced BUNDLE_PATH (committed .bundle/config =
   attacker-authored input, and a scan/apply WRITE-target root) must
   now, after ~ expansion and lexical normalization, stay contained in
   the project root — otherwise the root is skipped with a
   `gem_bundle_config_path_ignored` stderr warning naming the value.
   Windows rooted forms (`\evil`, `C:evil`) take the strict branch.
   Env-sourced BUNDLE_PATH stays trusted (user's own environment) but
   is normalized for dedup. `normalize_lexically` is hoisted from the
   composer crawler into utils::fs and shared.

5. `~` EXPANSION: a leading `~`/`~/...` in BUNDLE_PATH expands against
   home (bundler File.expand_path), env-injectable via the _with_env
   seams for hermetic tests.

6. BUNDLE_PATH__SYSTEM: `"true"` makes bundler ignore the recorded
   path — the config entry now parses as unset and the fallback finds
   the system gem homes.

7. TEST HERMETICITY: the six crawler_ruby_e2e tests that read ambient
   BUNDLE_PATH/BUNDLE_APP_CONFIG now route through the new
   `get_gem_paths_with_env` seam; a new e2e pins env-root + gem-env
   fallback coexistence (finding 3).

8. CLI_CONTRACT.md: the stale "gem inspects only <cwd>/vendor/bundle"
   claim replaced with the real root model, the containment policy,
   and the multi-copy behavior.

TDD evidence (red -> green): dispatch-level
`find_all_packages_for_purls_carries_every_gem_store_copy`, crawler
`bundle_roots_probe_in_bundler_precedence_order`, and the new
`in_process_gem_multicopy.rs` (real binary apply/rollback over a
coexisting two-store tree) all failed on base — the flat copy stayed
byte-for-byte VULNERABLE while apply reported success — and pass now.

Live era-image proof (docker run --rm, socket-patch-test-gem-b1:gemx,
bundler 1.17.3): the baked pre-fix binary on a coexist fixture reports
status=success/applied=1 while the flat store's copy — loaded via real
GEM_HOME resolution in the container — still evaluates VULNERABLE; the
fixed binary reports applied=2 and both stores load FIXED.

Gates: touched files rustfmt-clean; cargo clippy --workspace
--all-features -D warnings clean; core --lib 2413 passed; cli --lib
430 passed; crawler_ruby_e2e 25, crawler_composer_e2e 32,
crawlers_empty_paths_e2e 13; e2e_gem hermetic 8; in-process gem+npm
multicopy suites; cli_gem_variant_mismatch_policy 6; docker_e2e_gem,
docker_e2e_vendor_gem, docker_e2e_pypi, docker_e2e_maven all green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…lass-split fallback-home failure semantics

Review-round fixes for the two verified Bugbot findings on #222.

Finding 1 (Medium): the containment guard's
`gem_bundle_config_path_ignored` was a bare eprintln inside the crawler —
it never reached any --json `warnings[]` and printed under --silent,
violating the repo-wide warning conventions (#219/#220 + the #223
omnibus silent fixes). The crawler is now print-free: the refusal is
RECORDED on `BundleStoreDiscovery.skipped_config_path`, and a shared
`config_path_ignored_warning(value)` builder feeds the CLI channels —
scan pushes it onto the same run-level channel as the PnP layout
refusals (JSON `warnings[]` on both the zero-package and >=1-package
envelopes; one stderr line gated on !json && !silent), and apply carries
it in its Envelope `warnings[]` plus one gated stderr line. Scoped like
the crawl that hit it: local mode, gem in --ecosystems/manifest scope.

Finding 2 (High, with nuance): with an env/config bundle root,
get_gem_paths appends the gem-env fallback homes and the multi-copy
fan-out patched EVERY copy with per-copy loud-fail — so a gem present in
both the bundle store and a shared home (rvm @global, root-owned system
dir) failed the WHOLE run on a permission failure or variant mismatch
THERE, even though the copy bundler loads patched fine. Patching a
shared home's copy is not itself wrong (plain apply always patched
GEM_HOME when no store existed); the defect was failure semantics
crossing store classes. Fix: discovery's store list is exposed
(`RubyCrawler::discover_bundle_stores`, fs-probes only) and apply's gem
fan-out classes each copy — bundle-path store copies stay PRIMARY
(loud-fail, unchanged); gem-env fallback-home copies become BEST-EFFORT
once at least one store copy applied: a variant mismatch or write
failure there is a per-copy non-fatal Skipped event
(`gem_fallback_home_skipped`, detail names the path and reason; gated
stderr twin), never a run failure. Parity edge kept: with NO bundle-store
copy (the historic fallback-only layout, and every --global run) the
home copy IS primary and keeps loud-fail exactly as pre-#218 apply.

TDD evidence (red -> green on the rebased tip): scan/apply --json
missing the warnings[] entry and the --silent leak (3 tests,
in_process_gem_config_warning.rs); mismatched-home-copy exit 1 and
Failed-event-on-strict-refusal (in_process_gem_fallback_home.rs), with
fallback-only loud parity and both-copies-patched pinned green
throughout. CLI_CONTRACT.md documents the copy classes and the warning
channels.

Gates: touched files rustfmt-clean; cargo clippy --workspace
--all-features -D warnings clean; core --lib 2535, cli --lib 436;
crawlers::ruby 50, crawler_ruby_e2e 25; gem+npm multicopy 2+2;
apply_network 11, apply_invariants 4, cli_gem_variant_mismatch_policy 6,
cli_apply_silent 2, e2e_gem hermetic 8 (6 shown +cache selftests),
e2e_scan, cli_scan_silent, docker_e2e_gem — all green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…every coexisting copy, contain config-sourced roots (#222)

Post-merge audit follow-up on #218 (gem crawler flat-BUNDLE_PATH
discovery), mirroring the #216 npm multi-copy precedent (0433bcb).

1. MULTI-COPY (most severe): bundler's scoped `<engine>/<abi>/gems`
   and flat `gems/` stores coexist under one root, each holding a REAL
   physical copy of the same gem@version — exactly the state #218's
   tests create. First-wins merging resolved the purl to ONE path, so
   apply patched one store and reported success while the other
   bundler loaded pristine (vulnerable) bytes. Fix mirrors #216:
   `find_all_packages_for_purls` now routes the release-variant
   ecosystems through an accumulating `merge_variant_copies` (reusing
   `push_path`, base-PURL keyed, precedence order kept) and apply's
   variant branch fans out per copy for gem — per-copy Applied events,
   `summary.applied` counts each copy, a copy matching no variant
   fails loudly. Rollback already carried every copy via
   `merge_qualified` and its per-path grouping; the new in-process
   suite pins both directions. PyPI/Maven deliberately keep the
   one-representative contract (the nuget `already_patched`
   double-patch regression from #216's second commit), as do all
   collapsing consumers (vendor/vex/setup/get/repair-vendor).
   scan --sync patches every copy too (it runs the real nested apply);
   scan's inventory stays purl-level, byte-identical to npm's
   crawl_all purl-dedup precedent.

2. PRECEDENCE: roots probed local-config > env > default vendor/bundle
   (bundler's real precedence; the old order was inverted), so
   first-representative consumers pick the copy bundler actually loads.

3. REGRESSION vs pre-#218: env/config roots no longer trip the
   `gem env` fallback early-return — only the historic project-local
   vendor/bundle probe keeps it. Default gems (rexml/json) live only
   in the DEFAULT/system gem homes, so an env-BUNDLE_PATH project gets
   those homes appended (deduped) again.

4. SECURITY: a config-sourced BUNDLE_PATH (committed .bundle/config =
   attacker-authored input, and a scan/apply WRITE-target root) must
   now, after ~ expansion and lexical normalization, stay contained in
   the project root — otherwise the root is skipped with a
   `gem_bundle_config_path_ignored` stderr warning naming the value.
   Windows rooted forms (`\evil`, `C:evil`) take the strict branch.
   Env-sourced BUNDLE_PATH stays trusted (user's own environment) but
   is normalized for dedup. `normalize_lexically` is hoisted from the
   composer crawler into utils::fs and shared.

5. `~` EXPANSION: a leading `~`/`~/...` in BUNDLE_PATH expands against
   home (bundler File.expand_path), env-injectable via the _with_env
   seams for hermetic tests.

6. BUNDLE_PATH__SYSTEM: `"true"` makes bundler ignore the recorded
   path — the config entry now parses as unset and the fallback finds
   the system gem homes.

7. TEST HERMETICITY: the six crawler_ruby_e2e tests that read ambient
   BUNDLE_PATH/BUNDLE_APP_CONFIG now route through the new
   `get_gem_paths_with_env` seam; a new e2e pins env-root + gem-env
   fallback coexistence (finding 3).

8. CLI_CONTRACT.md: the stale "gem inspects only <cwd>/vendor/bundle"
   claim replaced with the real root model, the containment policy,
   and the multi-copy behavior.

TDD evidence (red -> green): dispatch-level
`find_all_packages_for_purls_carries_every_gem_store_copy`, crawler
`bundle_roots_probe_in_bundler_precedence_order`, and the new
`in_process_gem_multicopy.rs` (real binary apply/rollback over a
coexisting two-store tree) all failed on base — the flat copy stayed
byte-for-byte VULNERABLE while apply reported success — and pass now.

Live era-image proof (docker run --rm, socket-patch-test-gem-b1:gemx,
bundler 1.17.3): the baked pre-fix binary on a coexist fixture reports
status=success/applied=1 while the flat store's copy — loaded via real
GEM_HOME resolution in the container — still evaluates VULNERABLE; the
fixed binary reports applied=2 and both stores load FIXED.

Gates: touched files rustfmt-clean; cargo clippy --workspace
--all-features -D warnings clean; core --lib 2413 passed; cli --lib
430 passed; crawler_ruby_e2e 25, crawler_composer_e2e 32,
crawlers_empty_paths_e2e 13; e2e_gem hermetic 8; in-process gem+npm
multicopy suites; cli_gem_variant_mismatch_policy 6; docker_e2e_gem,
docker_e2e_vendor_gem, docker_e2e_pypi, docker_e2e_maven all green.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>