chore(ci): let pnpm-version follow packageManager by default

[BryanFRD]

reusable-ci-node.yml and reusable-ci-astro.yml default pnpm-version to '10'. A caller that omits the input therefore builds on pnpm 10 no matter what its own packageManager says, and nothing in the caller hints at it. As repositories move to 12, that default quietly tests something nobody runs locally.

The default becomes empty, which is what pnpm/action-setup needs to read packageManager from the caller's package.json. Every caller that already passes pnpm-version: '' (FerrVault-Cloud, FerrTrack-Cloud, FerrGrowth-Cloud, FerrFleet-Cloud, FerrLens-Cloud) keeps the exact behaviour it has, and the pin becomes the single source of truth instead of one of three answers.

Callers that pin a version deliberately are unaffected: Status passes '12.3.4' and keeps it.

Order matters. MCP is the only caller relying on the old default, and it had no packageManager field at all. FerrLabs/MCP#339 pins it to pnpm@12.3.4 and must land first, otherwise its next run asks the action to resolve a version from a file that does not declare one.

[ferrfleet]

Behaviour checks out: pnpm/action-setup treats an empty version as unset and falls back to packageManager, and the five callers already passing pnpm-version: '' are live proof of that path. Failure mode when no pin exists is a loud "No pnpm version is specified" at setup, not a silent wrong version, which is the right way round.

On ordering: MCP pins the reusable at 539e9ac, so merging this does not touch its CI until that SHA is bumped. The constraint is real but it binds at the bump (the Renovate PR), not here, so this can land first if FerrLabs/MCP#339 stalls.

Two nits inline on the new description, no blocking findings.

[ferrfleet]

Nit: "the caller's package.json" is ambiguous for the monorepo case this workflow explicitly supports. defaults.run.working-directory does not apply to uses: steps, so pnpm/action-setup reads package_json_file: package.json at the repo root, never working-directory's. That is the right file for a pnpm workspace (the root holds the pin), but a caller with working-directory: apps/web and no root packageManager will get "No pnpm version is specified" from a file they weren't looking at.

Suggested change

	pnpm version for `pnpm/action-setup`. Empty, the default, makes the
	action read `packageManager` from the caller's package.json, which
	keeps CI on the version the repository actually pins. Set it only for
	a repository that has no `packageManager` field.
	pnpm version for `pnpm/action-setup`. Empty, the default, makes the
	action read `packageManager` from the package.json at the repository
	root (not the one under `working-directory`), which keeps CI on the
	version the repository actually pins. Set it only for a repository
	whose root package.json has no `packageManager` field.

[ferrfleet]

Nit: same wording as the node workflow, and it matters more here since cache-dependency-path documents the sub-package layout explicitly.

Suggested change

	pnpm version for `pnpm/action-setup`. Empty, the default, makes the
	action read `packageManager` from the caller's package.json, which
	keeps CI on the version the repository actually pins. Set it only for
	a repository that has no `packageManager` field.
	pnpm version for `pnpm/action-setup`. Empty, the default, makes the
	action read `packageManager` from the package.json at the repository
	root (not the one under `working-directory`), which keeps CI on the
	version the repository actually pins. Set it only for a repository
	whose root package.json has no `packageManager` field.