Stale CLI pins: read workspace packages, and report pinnedCli on info --json #445

Follow-ups deliberately left out of #443, which made taskless init name any package.json pin of @taskless/cli / @taskless/cli-nightly that would run an older CLI than the one that just ran (pinnedCli on init --json, plus a notice on the human path).

1. Read workspace packages, not only the root package.json

findStalePins (packages/cli/src/install/pinned-cli.ts) reads <cwd>/package.json and <cwd>/node_modules/<name>/package.json only. In a monorepo the pin usually lives in a workspace package, so after an upgrade that migrated .taskless/, CI running that package's pinned CLI fails with SCAFFOLD_VERSION_MISMATCH and nothing warned. That is the same silent break #443 exists to prevent.

Things to settle:

• Workspace discovery: pnpm-workspace.yaml packages: globs, and the workspaces field (npm/yarn, array or { packages } form).
• location needs to name the package, e.g. packages/app/package.json: devDependencies, and the envelope shape may want a separate package field rather than overloading location.
• Installed versions: with pnpm, the workspace package's own node_modules/<name> link is what that package runs; with hoisting (npm/yarn) it may only exist at the root.
• Glob expansion without adding a dependency, and a bound on how much of the tree is walked.

2. Report pinnedCli on info --json

The update recipe's step 4 currently gets the pins from init output, or tells the agent to re-run init --json (safe, since it is a no-op on a current project, but init is not a read command). update is reached after a version move, possibly in a later session, so the agent should be able to read the pins from the read-only command it already runs in step 1.

Things to settle:

• info --json schema change (packages/cli/src/schemas/info.ts) and the info recipe.
• findStalePins needs the running version, which info already knows.
• Then point update.md step 4 at info --json instead of init --json.

Refs #443