null entries in a subgraph host's widgets_values load as undefined on >=1.47, silently breaking pre-refactor workflows

### What happened?

On frontend 1.46.x, a `null` entry in a subgraph host node's `widgets_values` meant "no host override — fall through to the interior widget's value". That fallthrough is gone on ≥1.47.9: host `widgets_values` is now the authoritative value (it seeds the display *and* compiles into the prompt), and a `null` entry loads as `undefined` rather than deferring to the interior node.

The result is that any workflow saved before the ADR-0009 / widget-store refactor, whose host `widgets_values` contains nulls, now opens with dead promoted widgets — no error, no warning, no migration.

This is not hypothetical: nulling those entries was the **documented recovery workaround** for #13601, so the workflows most likely to hit this are the ones whose owners followed the advice in that thread.

### Evidence

A workflow saved under 1.46.x, subgraph host node with:

```json
"widgets_values": [null, null, null, null, null, null, null, 3358]
```

loaded on **frontend 1.47.11 / core v0.29.2** — 5 of the 8 promoted widgets come back with `value: undefined`:

```
value (customtext) -> "" ok
value_1 (number) -> undefined BROKEN
value_2 (number) -> undefined BROKEN
value_3 (number) -> undefined BROKEN
start_index (number) -> undefined BROKEN
value_4 (number) -> undefined BROKEN
(the one non-null entry, 3358, loads fine)
```

The interior nodes still hold their real values — only the host-level view is broken — so the information needed to migrate is present in the file.

### Steps to Reproduce

1. On a build ≤1.46.15, create a subgraph and promote a few numeric widgets to the host node.
2. Set every entry of the host node's `widgets_values` to `null` (the #13601 workaround), or otherwise obtain a workflow saved with nulls there.
3. Open that workflow on ≥1.47.9.
4. Inspect the host node's promoted widgets: the numeric ones have `value === undefined` and render blank/NaN instead of picking up the interior values.

### How is this affecting you?

Workflows that opened fine before a routine frontend update now open with unusable promoted controls, and the failure is silent — nothing in the console indicates a migration happened or failed. Recovery means hand-editing JSON to write concrete values into `widgets_values`, which requires knowing the slot ordering.

Because the null-out was the recommended fix in #13601, this preferentially breaks workflows belonging to users who reported or worked around that bug.

### Suggested fix

A load-time migration: when a host `widgets_values` entry is `null`/absent, resolve the value from the linked interior widget (the pre-1.47 semantics) instead of leaving it `undefined`. That keeps the new authoritative-host-value model while letting legacy files self-heal on open.

### ComfyUI Frontend Version

1.47.11 (core v0.29.2). The behaviour change was already present at 1.47.9; not tested on 1.49.x, which landed #10392 (`widgets_values_named`) in this same serialization area.

### Browser

Chrome — the broken state is in the loaded graph model, so it is not browser-specific.

### Additional Context

Follow-up to #13601 (the original freeze, which I can confirm is fixed on 1.47.11 — see my comment there). This issue is the inverse failure introduced by the same refactor.

Start by tracing frontend load-time deserialization for subgraph host widgets_values and how each host slot links to its interior widget. Reproduce the pre-1.47 workflow with null entries, then verify that opening it resolves legacy null or absent slots from the interior values without changing the authoritative host-value behavior for concrete entries.

Written by the indexing model from the issue text.