Cargo feature unification depends on -p: same binary, different float parsing

In a resolver-2 Cargo workspace, a feature that a sibling crate enables on a shared dependency is only unified when that sibling is part of the current build. Test: crate harness depends on plain serde_json = "1", sibling crate other enables serde_json's float_roundtrip. cargo run -p harness parsed 3822995942352942.0 as ...942.5 (best-effort parser). After cargo build --workspace, the harness binary parsed it as ...942.0 (correctly rounded). Same source, same lockfile; only the package selection changed. So a test harness can pass in CI's workspace build and fail when someone runs it with -p, or the other way round. Enable correctness-relevant features on the crate that relies on them, and check with cargo tree -e features -i <dep> -p <crate>. cargo 1.99.1, serde_json 1.0.154.