refactor: simplify pixi run platform resolution, make implicit install platform sticky in core

[wolfv]

Follow-up to the sibling-environment platform leak fix (ffe170647 / deaf45a63); stacked on those commits, so this shows them until that PR merges — only the top two commits are new.

refactor(run): resolve run platform per task environment, not up front

The pre-loop block in run.rs computed a "run platform" from the top-level environment (--platform, else the platform the default/-e environment was last installed for) and validated --platform membership against that environment only. But tasks execute in their own environments, so those answers applied to the wrong environment whenever a task lived elsewhere.

--platform membership is now checked per executable task against the environment the task actually runs in, next to the existing runnability check, and the now log-only locals (installed_platform, run_platform, best_declared_platform) are gone. This also fixes a UX gap: pixi run --platform X task-in-gpu-env now errors with platform 'X' is not part of environment 'gpu' instead of the misleading "no platform supported by it matches the current system".

refactor(install): make the implicit install platform sticky in core

pixi run kept an environment on the platform it was last installed for by mutating the global LockFileDerivedData::target_platform override per task environment inside its execution loop — shared mutable state standing in for a per-environment decision, and stickiness that other prefix consumers (pixi shell, pixi install) never got, so they could silently flip a prefix that was deliberately installed for another declared platform.

The stickiness now lives in LockFileDerivedData::install_platform: with no explicit --platform, prefer the platform recorded in the environment's conda-meta/pixi marker (when the environment still declares it) over the host's best declared platform. The lock-file hash also goes through install_platform, so hash and install can no longer disagree. target_platform is back to meaning only the explicit --platform flag.

Task search already preferred the installed platform with the same env-membership guard; both now share the new Environment::installed_declared_platform, and the dead installed_resolved_platform_name is removed.

Deliberate behavior changes

• A plain pixi install / pixi shell now keeps a prefix on the declared platform it was last installed for instead of re-targeting the host's best match; pass --platform to re-target.
• Unlike an explicit --platform, the sticky platform still runs the lock-file minimum-requirements validation, so a prefix the machine can no longer run errors at install time instead of installing and failing afterwards.

🤖 Generated with Claude Code

[hunger]

I like the sticky platform, but I do see a problem with how the "can this run here?" validation works now: a deliberately cross-installed prefix goes from "silently re-targeted, succeeds" to "errors on every install until you repeat --platform or re-set override vars". This is a behavior change we should clear with @ruben-arts first. If we decide to go for this behavior change: We would need tests to hammer this behavior down.

I also am not too happy that we detect errors now only after the lockfile was re-resolved (and maybe rewritten). IMHO we should leave the lockfile alone when we error.

Like all AI code, the code could be DRYer as well. E.g. Some errors are just copied verbatim.