Fixes flutter#172006.

`flutter build web --wasm` already produces both a Wasm and a JS build
of the app so the runtime web loader can fall back to JS at runtime on
browsers that don't support WasmGC. `flutter run --wasm` only produces
the Wasm build, so attempting to run on a non-WasmGC browser (e.g.
iOS Safari) fails with:

  FlutterLoader could not find a build compatible with configuration
  and environment.

Bring the run path in line with build by returning a list of compiler
configurations (Wasm + JS when --wasm is set, JS-only otherwise) from
ResidentWebRunner._compilerConfigs and passing it through to
WebBuilder.buildWeb at both call sites.

Extract the JsCompilerConfig.run constructor into a local variable so
the JS-fallback (Wasm + JS) and JS-only branches share a single
source. Pure refactor — no behaviour change.

* lib/src/isolated/resident_web_runner.dart:
  - Omit obvious JsCompilerConfig type annotation on the dedup'd local
    introduced by the previous refactor (omit_obvious_local_variable_types).

* test/general.shard/resident_web_runner_test.dart:
  - Reorder web/compiler_config.dart import so the web/ block stays
    alphabetical (directives_ordering).
  - Replace const BuildInfo(BuildMode.debug, null, ...) with BuildInfo.dummy
    in the new --wasm regression test — the linter confirmed they're
    equivalent objects (use_named_constants).
  - Drop two obvious ResidentWebRunner type annotations on locals where
    the right-hand side already includes 'as ResidentWebRunner'
    (omit_obvious_local_variable_types).

Verified locally with 'flutter analyze' on both files: no issues found.

Addresses review feedback from @mdebbar and @bkonyi: replace the
if/else with two return statements by a single list literal that uses
a collection-if for the Wasm config. Behaviour is unchanged.

…nshahan

@nshahan raised a real concern on flutter#186253: it wasn't clear from the
code or tests which JavaScript compiler runs in which mode when the
new '--wasm' JS fallback is picked, or whether the fallback silently
loses DDC-based dev tooling.

Both concerns are documentation, not behavior — the code already picks
JsCompilerConfig (dart2js) unambiguously. Make that explicit:

  * Docstring on ResidentWebRunner._compilerConfigs now spells out the
    full mode / --wasm matrix in a table, calls out which branch of
    _runOnce actually consults this getter (isDebug && !webUseWasm
    routes through WebDevFS + DDC and does not), and explains that
    hot reload was already unavailable with --wasm before this getter
    was added (see reloadIsRestart) — the new JS fallback only widens
    browser compatibility, it does not remove tooling.

  * Assertions in the two --wasm regression tests now check the
    concrete runtime types (WasmCompilerConfig / JsCompilerConfig) and
    their relative order — not just the CompileTarget enum count — so
    the test itself documents 'JS side is dart2js, never DDC'. Test
    names also updated to reflect the fallback-preference ordering.