Fix package manager detection for nested package scripts

[Valley-15]

Objective

Fixes #61902.

When a package.json belongs to a nested workspace package, Zed's generated package-script tasks can incorrectly fall back to npm even when the workspace root specifies pnpm or another package manager. This affects both the package-script task and the package.json gutter runnable.

Solution

• Add shared package-manager detection for package scripts.
• Walk from the nested package directory through its ancestor directories and use the nearest package.json that declares a package manager.
• Fall back to the worktree's pnpm-lock.yaml or yarn.lock when no package manager is declared.
• Keep the existing npm fallback when no package manager can be detected.
• Reuse the shared detection logic for both JSON and TypeScript task providers.
• Preserve the nested package directory as the task working directory.

Testing

• Added regression coverage for:
  • package manager detection from an ancestor package.json
  • preferring the nearest package.json
  • pnpm lockfile detection
  • yarn lockfile detection
  • npm fallback
• Ran cargo test -p languages --lib successfully: 95 tests passed.
• Ran cargo fmt -p languages --check.
• Ran git diff --check.

Reviewers can reproduce the issue using the workspace described in #61902: open a nested workspace package.json with a script while the root package.json declares packageManager: "pnpm@11.17.0", then run the script from the gutter or task picker.

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content adheres to Zed's UI standards
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

---

Release Notes:

• Fixed package-script tasks in nested workspaces incorrectly using npm instead of the workspace's detected package manager.