Node templates workload: switch from static content to CDN bundle snapshot

## Context

The Node templates workload (`src/Workloads/Templates/Node/`) currently uses `TemplatesContentSource=static`, packing v2 template content from in-repo files under `content/v2/`. Per the dev notes (`README.DEV.md`), this is because the upstream extension bundle's `StaticContent/v2/templates/templates.json` did not yet publish Node entries when the workload was authored (only Python).

To keep packs channel-aware, Node opts in to `FilterTemplatesByBundleChannel=true`, which fetches `bin/extensions.json` from the **latest listed** bundle of `$(BundleChannel)` (resolved live from CDN `index.json`) and subsets `content/v2/templates/templates.json` against `content/v2/templates/_bindings.json`.

## Problem

After #5365, the bundles workload and the bundle-backed templates workloads share `$(BundleChannel)` and pin a per-channel `$(BundleVersion)` in `eng/build/Workloads.Templates.SourceBundleVersion.props`, so for a release tag like `templates-node/v1.2.0-preview`:

- **Python (cdn mode):** snapshots StaticContent from the **pinned** preview bundle (`4.42.0`). Fully reproducible.
- **Bundles workload:** ships the **pinned** preview bundle (`4.42.0`).
- **Node (static + filter):** uses the pinned `BundleVersion` for the workload's version metadata, but per-template subsetting still resolves "latest listed" preview from CDN at pack time, which may differ from the pinned version. Two packs from the same tag on different days can produce different content. ❌

## Proposal

Once Node template entries are published in the upstream bundle's `StaticContent/v2`, flip the Node workload from `TemplatesContentSource=static` to `cdn` so it snapshots from the same pinned `$(SourceBundleVersion)` as Python:

- Remove `TemplatesContentSource=static`, `FilterTemplatesByBundleChannel=true`, and the in-repo `content/v2/` tree from `src/Workloads/Templates/Node/`.
- Set `TemplatesStackLanguageFilter=JavaScript;TypeScript` (the existing CDN-mode filter handles language subsetting).
- Delete the per-channel scripts that are then orphaned (`eng/scripts/fetch-bundle-extensions-json.ps1`, `eng/scripts/filter-node-templates-by-bundle.ps1`) and the static-mode branches in `eng/build/Workloads.Templates.targets` if no other workload uses them.
- Refresh `src/Workloads/Templates/Node/README.DEV.md` to describe the new pipeline.

## Prerequisites

Upstream bundle (`Microsoft.Azure.Functions.ExtensionBundle*`) must publish v2 Node template entries under `StaticContent/v2/templates/templates.json` across stable / preview / experimental channels. Until that lands this issue is blocked.

## Acceptance criteria

- `dotnet pack` on the Node workload at a release tag produces byte-identical output across runs (no live CDN `index.json` lookup).
- `func new` against an installed Node templates workload still surfaces the same template set users see today.
- Pack-time and runtime parity with the Python templates workload.

## References

- #5364 (build: infer bundle channel from properties)
- #5365 (build: infer bundle channel for templates workloads)
- `src/Workloads/Templates/Node/README.DEV.md` (current static-mode rationale)
- Templates Workload Spec §6.1

First verify that the upstream extension bundles publish Node entries in StaticContent/v2/templates/templates.json for every channel. Then read src/Workloads/Templates/Node/README.DEV.md, eng/build/Workloads.Templates.targets, Workloads.Templates.SourceBundleVersion.props, and the two named fetch/filter scripts; run dotnet pack for the Node workload and compare release-tag outputs. Done means the pinned CDN snapshot is used, obsolete static-mode files are removed where unused, and the acceptance checks pass.

Written by the indexing model from the issue text.