Set viewId on the text input configuration (fixes dead keyboard input on Windows)

[LarryHsiao]

Set viewId on CustomTextEdit's TextInputConfiguration, without which text input is dead on Windows.

Flutter's Windows embedder rejects TextInput.setClient when the configuration carries no viewId:

PlatformException(Bad Arguments, Could not set client, view ID is null.)
PlatformException(Internal Consistency Error, Set editing state has been invoked, but no client is set.)

The connection never attaches. That is fatal rather than merely noisy, because CustomTextEdit has no hardware-key fallback for printable characters the way CustomKeyboardListener does — so with the connection dead, letters and digits have no route to the terminal at all. Keys that map to a TerminalKey (Enter, arrows, Ctrl-combos) still work via the Focus onKeyEvent path, which makes the failure look puzzlingly selective: Enter responds, typing does not.

macOS tolerates the omission through its implicit view, so this only surfaces on Windows.

• lib/src/ui/custom_text_edit.dart — pass View.of(context).viewId, matching how Flutter's own EditableText populates the field.
• test/src/terminal_view_test.dart — regression test asserting the viewId reaches TextInput.setClient. It fails on master (Expected: <0>, Actual: <null>) and passes with the fix, on any platform.

Verified end-to-end on Windows 11 with Flutter 3.38.7 in a real app embedding TerminalView over a ConPTY-backed shell: before, every printable keystroke was dropped; after, all input works and the exceptions are gone.

One note for whoever runs this locally: master's dev_dependencies pin dart_code_metrics: ^5.0.0, which cannot co-resolve with the test_api that current flutter_test requires, so flutter pub get fails on recent SDKs. I verified the suite on a branch with that dev-dependency dropped (112 passing; the only failures are the pre-existing textScaler goldens, which are macOS-rendered and fail on Windows at any commit). That resolution problem is untouched by this PR.