[programgen] Guard references to conditionally-created resources (Python & NodeJS) - #23634

## Description

Splits the `l3-range-ref` language conformance test into three focused
tests so that each range-reference codegen path can be marked pass/fail
independently per language. Previously all four reference patterns lived
in one program, so a single broken pattern forced the whole test into a
language's `expectedFailures`, masking the others.

New tests:

- **`l3-range-list-ref`** — numeric and list ranges, indexed references
(`numResource[0]`, `listResource[1]`), and dynamic indexing
(`listResource[range.key]`, the pulumi#14037 quote/index-rewrite path).
- **`l3-range-map-ref`** — a map range indexed by a string key
(`mapResource["k1"]`).
- **`l3-range-bool-ref`** — dereferencing a conditionally-created
(boolean `range`) resource (`boolResource.name`).

This PR is a pure test refactor — **no program-generation changes**.
Per-language status is recorded exactly as it stands today:

| Test | PCL | Python | NodeJS | Go |
|------|-----|--------|--------|----|
| `l3-range-list-ref` | ✅ pass | ✅ pass | ✅ pass | ❌ expected-fail
(syntax errors) |
| `l3-range-map-ref` | ✅ pass | ❌ expected-fail (`__getitem__` overload)
| ❌ expected-fail (`Property 'k1'`) | ❌ expected-fail |
| `l3-range-bool-ref` | ✅ pass | ❌ expected-fail (`union-attr`) | ❌
expected-fail (`Output<string> \| undefined`) | ❌ expected-fail |

Follow-up pulumi#23634 (stacked on this PR) fixes the Python and NodeJS
program generation so `l3-range-bool-ref` passes for both, removing it
from their expected-failure lists.

## Checklist

- [x] Conformance suites run locally for PCL, Python
(Default/TOML/Classes), NodeJS (TSC/TSNode/Bun), and Go
- [x] `expectedFailures` updated per language; `l3-range-list-ref`
goldens committed

… NodeJS) (pulumi#23639)

## Description

Stacked on pulumi#23634.

A resource with a map `range` option was collected into an ordered list
(Python `list`, NodeJS array) and then referenced by its map key
(`mapResource["k1"]`), which does not type-check — a list/array can't be
indexed by a string. Python failed mypy `__getitem__` overload; NodeJS
failed `Property 'k1' does not exist on type 'Target[]'`.

Generate a **key-indexed, strongly-typed** collection for map ranges:

- **Python:** `dict[str, T]` populated by `m[range['key']] = ...`
- **NodeJS:** `{[key: string]: T}` populated by `m[range.key] = ...`

Detection reuses the existing inline map check at the range site
(`pcl.UnwrapOption(rangeExpr.Type()).(*model.MapType)`) — no new helper.

### Also in this PR

- **Tighten list typing:** numeric/list ranges are now `list[T]` in
Python instead of `list[Any]` (NodeJS already used `T[]`).
- **Unique Python loop variable per range:** each range statement binds
`<resource>_range` instead of the shared `range` name. Reusing `range`
type-locked its element type across loops — a numeric range fixed it to
`dict[str, int]`, which then rejected a later map range's string
`range['key']` as a dict key. Unique names remove the coupling (and stop
shadowing the `range` builtin). NodeJS already block-scopes each loop's
`range` with `const`, so it needs no change.

`l3-range-map-ref` now type-checks under mypy and pyright and compiles
under tsc, and is removed from the Python and NodeJS expected-failure
lists. Go has unrelated range program-generation bugs and is left
failing.

## Checklist

- [x] Conformance: full `l3-range*` family passes for Python
(Default/TOML/Classes) and NodeJS (TSC/TSNode/Bun)
- [x] `pkg/codegen` program-gen goldens regenerated (components-pp,
python-regress-14037-pp, unknown-resource-pp) and pass
- [x] Changelog entry added