ci: fix CFS template reference so it resolves against this repository

[wenytang-ms]

Follow-up to #1708, which broke YAML compilation for every pipeline in .azure-pipelines/.

The failure

The 'stages' parameter is not a valid StageList.
/.azure-pipelines/nightly.yml: File /azure-pipelines/npm-cfs.yml not found in repository
https://dev.azure.com/mseng/1ESPipelineTemplates/_git/MicroBuildTemplate branch refs/tags/release

All five pipelines pass their steps into an extends template that lives in another repository. A relative template path is resolved against the file that does the including, and in this case that file is the extends template, not the pipeline. So npm-cfs.yml was looked up in the template repository:

Pipeline	Extends template	Resolved to
nightly.yml, rc.yml	azure-pipelines/MicroBuild.1ES.Official.yml@CustomPipelineTemplates	/azure-pipelines/npm-cfs.yml in MicroBuildTemplate
ci.yml, release.yml, release-nightly.yml	v1/1ES.*.PipelineTemplate.yml@1esPipelines	/v1/npm-cfs.yml in 1ESPipelineTemplates

The fix

Qualify the reference with an absolute repository path and @self, which the template documentation describes as the way to refer back to the extending pipeline's own repository:

- template: /.azure-pipelines/npm-cfs.yml@self

Verification

Compiled through the Azure DevOps preview API (previewRun, no build queued) against main and against this branch:

Pipeline	main	this branch
1ES-Nightly (16482)	template not found	compiles
1ES-RC (16483)	template not found	compiles
JavaPack-Release-Nightly (21191)	template not found	compiles
JavaPack-Release (21192)	template not found	compiles
1ES-CI (16481)	not previewable, definition is disabled	not previewable

The expanded YAML places the steps in the required order, for both the Windows MicroBuild jobs and the Linux release jobs:

1. npm_config_userconfig variable
2. NodeTool@0 / UseNode@1
3. npm config set registry ... --userconfig=...
4. NpmAuthenticate@0
5. npm install / npx ...

1ES-CI cannot be previewed because the definition is currently disabled in the VSJava project, which is also why merging #1708 did not surface this. It carries the identical one line change.

Still unverified, and only observable on a real run: whether the build identity can authenticate against the vscjava feed. All five definitions use projectCollection job authorization, so the token belongs to the collection level build service, while the feed grants contributor to the VSJava project level build service. A 401 on npm install would point there rather than at this change.