fix(input-processing): InputManager.CreateFlow crashes with ArgumentNullException when no IMessageHandler is registered

[Vasar007]

Summary: InputManager.CreateFlow(string) (lines 81-100) detects an empty/whitespace storage name and falls back to _defaultStorageName. As part of the fallback it calls ProjectV.Communication.GlobalMessageHandler.OutputMessage(...) — a process-wide static helper that holds a singleton IMessageHandler whose setter is SetMessageHangler (typo preserved). If no handler has been registered, OutputMessage throws ArgumentNullException("MessageHandler", …). OutputManager.CreateFlow(string) does NOT have this asymmetry — the same fallback only calls _logger.Info(...).

Where

• Sources/Libraries/ProjectV.InputProcessing/InputManager.cs — CreateFlow(string) lines 81-100.
• Adjacent: Sources/Libraries/ProjectV.Communication/GlobalMessageHandler.cs — process-wide static + SetMessageHangler typo.

Production impact

Any production caller of InputManager.CreateFlow that fails to register a GlobalMessageHandler ahead of time AND passes an empty/whitespace storage name crashes with ArgumentNullException. The asymmetry with OutputManager.CreateFlow (which logs only, no static-handler dependency) confirms the message-handler call is incidental to the fallback's actual contract.

Suggested fix (one of)

• (a) Remove the OutputMessage(...) call from InputManager.CreateFlow — the existing _logger.Info(...) call carries the same diagnostic message and OutputManager already operates this way. Simplest fix, restores symmetry.
• (b) Make GlobalMessageHandler.OutputMessage static null-tolerant (no-op when no handler is registered). Broader blast radius — every other caller of the static helper would change behaviour too.

While here

Rename the setter SetMessageHangler → SetMessageHandler (the typo is intentional today only because it preserves the public API; it can be fixed atomically when the call is touched).

Acceptance

• An additional InputManagerTests.CreateFlow_WithEmptyStorageName_FallsBackToDefaultAndReturnsNonNullFlow test lands in ProjectV.InputProcessing.Tests and passes without registering a GlobalMessageHandler — mirroring the analogous OutputManagerTests test that already exists today.
• No regression in the messaging seam — other call sites that rely on OutputMessage(...) continue to work when a handler IS registered.

Surfaced by

Phase 2 Test Coverage (milestone v0.9.8) — Test (Unit) stage on ProjectV.InputProcessing.Tests. Documented at Docs/Testing/Coverage/test-coverage.md (InputManager.CreateFlow row notes).