fix(schematics): require only exported devkit paths from the shipped schematics

[armando-navarro]

Fixes #3789

The shipped schematics now require @angular-devkit/schematics/tasks, which every devkit version accepts, instead of @angular-devkit/schematics/tasks/index.js, which the exports map in devkit 22.3 rejects.

Changes

All in compileSchematics in tools/build.ts.

• An esbuild alias rewrites @angular-devkit/schematics/tasks/index.js to @angular-devkit/schematics/tasks in the bundles.
• The two source files keep the index.js spelling, because the ESM spec run cannot import the bare tasks folder from the repo's devkit 21, which has no exports map.
• The build now fails if a bundle requires a subpath of an external package that is not listed in exportedSubpaths, and names the files that import it. The list holds @angular-devkit/schematics/tasks, @schematics/angular/utility and rxjs/operators, each of which is in its package's exports map.
• The external package list moves into a named externalPackages constant, which the check reads.

Behavior to know

When the repo's own devkit reaches 22.3 or later, the two source imports can switch to @angular-devkit/schematics/tasks and the alias can go.

Verification

• With the package built from this branch, the setup, add, deploy builder, v7 migration and v21 migration bundles all load with @angular-devkit/schematics 21.2.25 and 22.3.0-next.0. With the current canary, setup/index.js, deploy/builder.js and update/v21/index.js fail under 22.3.0-next.0.
• Removing the alias fails the build with:

  The schematics require package paths that exportedSubpaths does not list:
    @angular-devkit/schematics/tasks/index.js, imported by src/schematics/utils.ts, src/schematics/update/v21/index.ts
  

• npm run test:node: 342 specs, 0 failures.

[tyler-reitz]

LGTM. Two notes, neither blocking.

Verified the fix by loading the built bundles rather than reading the diff. All six load against @angular-devkit/schematics 21.2.25 and 22.3.0-next.0; the published canary fails under 22.3.0-next.0 on setup/index.js, deploy/builder.js and update/v21/index.js with ERR_PACKAGE_PATH_NOT_EXPORTED, the three files you name. Deleting the alias and rebuilding does produce the guard error, so the new check can actually fail.

One thing to fix if you agree: the move into externalPackages drops the comment explaining why typescript is external (tools/build.ts:407-408 on main, the one about resolving it at ng-update time instead of bundling ~3.5MB). Nothing fails if someone later removes that entry, the package just gets bigger quietly, so it is worth moving the comment along with the entry.

Observation only: exportedSubpaths is never checked against a real exports map, though the comment says each entry is in one. rxjs@next (9.0.0-beta.0) has no ./operators export, so that entry is already stale for the newest rxjs. Harmless while the peer is ~7.8.0, but the build cannot notice if an entry goes bad.