[abrichr]

Found while recording a TextEdit demonstration on macOS: converting the recording failed with unmapped key 'space'.

The macOS and X11 input observers report the space bar as the named key space with no character. Two places then lost it:

• merge_consecutive_keyboard_events (capture) builds the typed text from key characters only, so a space typed while neighbouring letters overlapped was dropped from the merged text, and a lone space became a KeyTypeEvent with empty text.
• The flow capture adapter treats an empty-text key.type as a named special key and looks it up in _KEY_NAME_MAP, which has no space, so it raised.

Changes:

• capture: a small _typed_character helper returns " " for the named space key; the shift-printable check and the text join use it. Ctrl+space and other chords still become shortcuts.
• flow: an unmodified named space in an empty-text key.type joins the current text run as " ", so recordings made with an already released capture also convert.

Testing:

• packages/capture: pytest tests/test_processing.py 20 passed. Four new tests: lone named space, named space between overlapping letters, shift+space, ctrl+space stays a shortcut. Control with the base processing.py: the three space-as-text tests fail; the ctrl+space test passes on both, as a guard.
• packages/flow: pytest tests/test_capture_adapter.py -n 4 55 passed. New test converts "synthetic", named space, "note" and expects one type event "synthetic note". Controls: base adapter plus base capture fails; either fix alone passes.
• ruff check passes on the changed files. ruff format --check reports the two capture files, but they are already unformatted on main, so I left formatting alone.
• On a macOS VM, the recording converted past the space key with this branch. It then hit a separate frame-lookup problem, which I am handling on its own.

Not tested: a live X11 recording, and Windows (its observer already reports a space character).