chore(devcontainer): fix rustup overlayfs errors and tasks race condition

[AlexCannonball]

📝 Summary

This PR addresses two independent infrastructural issues within the development environment configuration:

1. Toolchain Update Failures (rustup vs OverlayFS): Resolves container filesystem crashes when updating the Rust toolchain.
2. VS Code Task Provider Race Condition: Eliminates annoying error popups related to unregistered task types upon workspace initialization.
3. Linter Coverage Expansion: Maximizes code quality guarantees by broadening Clippy's scope in the VS Code task.

---

🛠 Bug Analysis & Architectural Fixes

1. The rustup OverlayFS Crash (os error 18)

• The Problem:
  The project utilizes a pre-built devcontainer image or pulls the stable toolchain using devcontainer features. When cargo fetch runs based on rust-toolchain.toml, rustup detects if the toolchain is outdated and attempts to upgrade it.
  By default, rustup downloads updates to a temporary directory and executes an atomic rename system call to replace the target toolchain folder. In Docker environments (which rely on OverlayFS filesystem abstraction), attempting to move or alter directories across the lower (read-only base image) and upper (writable container) layers breaks constraints. It results in a hard termination with an Invalid cross-device link (os error 18) error, completely stalling the workspace orchestration.

• The Fix:
  Added "RUSTUP_PERMIT_COPY_RENAME": "true" to containerEnv. This flag instructs rustup to bypass strict atomic mutations on Linux systems and fall back to a safe copy-and-delete behavior. This ensures seamless background toolchain alignment even if the container base image becomes stale over time.

2. The VS Code Task Type 'cargo' Race Condition

• The Problem:
  When the workspace is initialized or rebuilt, VS Code immediately eager-parses .vscode/tasks.json to index available build steps. At this exact microsecond, the rust-analyzer extension (which acts as the explicit provider for tasks marked with "type": "cargo") is still initializing in the background. Because the task engine demands validation before the language client injects its capabilities, VS Code throws a sequence of false-positive errors: there is no registered task type 'cargo'. Did you miss installing an extension....
  While tasks function normally once rust-analyzer completes its bootstrap cycle, this race condition pollutes the editor's notification hub and degrades the developer experience.

• The Fix:
  Migrated core tasks (build, clippy, test) to native "type": "shell" configurations with explicitly passed binary subcommands (e.g., cargo build). Because shell targets are a built-in platform primitive, VS Code validates them instantaneously without waiting for third-party extensions. The diagnostic engine downstream retains full functionality, as "problemMatcher": ["$rustc"] remains fully integrated.

3. Enhancing Linter Scope

• The Improvement:
  Appended the --all-targets argument to the cargo clippy pipeline. Standard clippy calls omit auxiliary assets like integration tests (tests/*), performance benchmarks, and compilation orchestration logic (build.rs). Enforcing linting coverage over all build outputs prevents unused code, dead imports, and architectural anti-patterns from bypassing local validations before triggering the remote CI matrix.