fix(server): keybinding defaults survive a stale entry, and Option+Enter sends now

[leonardoxr]

Stacked on #14 — both touch the composer.sendNow paragraph in docs/user/keybindings.md. Until #14 merges this diff includes it; the fix itself is the single commit f8fa512b0.

Problem

A real config here still carries a rule from before the follow-up chords split in two:

{ "key": "mod+shift+enter", "command": "composer.followUpOverride" }

That command no longer exists, so the entry is dropped as an issue — and syncDefaultKeybindingsOnStartup bailed on the whole file whenever any issue was present. Consequence: that config has received no default keybinding since the rename, and never would have. Measured against the real resolver, the composer chords resolved as:

cmd+enter       -> composer.sendNow
cmd+shift+enter -> composer.queueFollowUp
alt+enter       -> null          ← nothing bound; falls through to the editor as a plain Enter

Fix

Only a file that fails to parse as a whole skips the sync now — rewriting that would throw away whatever the user meant. Individual invalid entries are logged, dropped, and the backfill proceeds without them, so the dead rule disappears on the next start and the missing defaults land.

composer.sendNow also gains alt+enter as a second default, so "send this now" is reachable without leaving the home row. Per the existing precedence model, a config that already binds the command keeps its own shortcut.

Verification

• New test backfills defaults past an entry naming a command that no longer exists, seeded with the exact composer.followUpOverride line — fails on main-xavier, passes here; asserts the dead rule is gone and the user's own mod+j binding survives.
• keybindings (server) + keybindings (shared/web) + KeybindingsSettings.logic: 79 tests green. tsgo clean; lint/format clean.

Built with Claude Opus 5 on Oh My Pi.