feat: implement shell flavors and fix workspace-wide initialization

[pranavpurankar]

Description

This PR implements support for additional POSIX-compliant shells (sh, dash, ksh, busybox) by implementing suggested "Flavor" architecture to the Bash shell struct. This fixes the limitation where these shells were not recognized during environment activation.

Key Improvements & Thought Process:

1. Arch Refactor: Following feedback in feat: added support for sh ShellEnum #2077, I converted Bash from a unit struct to a formal struct containing a BashFlavor enum. This allows for fine grained control over shell specific syntax if needed in the future while maintaining a clean, unified POSIX interface.

2. Avoiding Breakage and Ripple-effect: Unlike previous attempts, this PR provides the necessary stiching code for the entire Rattler workspace. I identified and updated all initialization points in the Python bindings (py-rattler), Linux menu integrations (rattler_menuinst), and link script logic to prevent compilation failures.

Fixes #1224 (support more shell type for ShellEnum)

How Has This Been Tested?

I performed a split execution test strategy using a specialized Ubuntu (24.04.4 LTS) container environment to ensure isolation:

1. Unit & Regression Testing: Ran the full rattler_shell test suite. All 27 core activation/deactivation tests passed, including new test cases for dash.

2. Cross-Language Verification: Verified the Rust-to-Python boundary by checking the py-rattler crate compilation.

3. Ensured the rattler_menuinst Linux integration correctly initializes the new Bash(Bash::default()) struct.

4. Snapshot Testing: Generated and verified new insta snapshots for dash deactivation to ensure the generated shell scripts are syntactically correct for POSIX compliance.

5. Lint Checking: Validated the workspace using cargo clippy --all-targets -- -D warnings and cargo fmt --all.

AI Disclosure

• This PR contains AI-generated content.

• I have tested any AI-generated content in my PR.

• I take responsibility for any AI-generated content in my PR.

• Purpose: Planning, Understanding code base, Stability, Optimization.

• Tools: Antigravity IDE

• Models: Claude Opus 4.6 (Thinking) and Gemini 3.1 Pro (Low)

• Prompt: Assisted in structuring a verbose code and optimizing it. Also helped in writing comments, and mentored just like core maintainers whenever I stuck at something. Played crucial role in understanding the overall crate structure and it's dependencies this where I indentified the ripple-effect. Last but not least helped me writing PR description to meet project standards.

Checklist:

• I have performed a self-review of my own code

• I have commented my code, particularly in hard-to-understand areas

• I have made corresponding changes to the documentation

• I have added sufficient tests to cover my changes.

[pranavpurankar]

Hi @baszalmstra and @wolfv,

I noticed #2119 is also touching the activation logic for performance. My PR (#2259) focuses on architecture for shell flavors (Dash/Busybox). I've been looking at the run_activation_fast_path logic in #2119. I want to ensure that the Rust base environment calculation remains 100% consistent with the POSIX specific flavors I'm introducing in #2259.

Here is scenario: If a user is using Dash, does the way we "prepend" to PATH in Rust match exactly how dash would have done it in a script?

Potential problem: Vee1e's code (PR #2119) has a function called compute_activation_env might create a conflict with PR#2259, because somehow calculations needs to be aware of the Flavor.

I just want ensure they play well together