test(keymaps): hard timeouts + serialise the CI job behind test

User reported the editor-keymaps CI job hung for 30 minutes before
"Has been cancelled" — twice in a row. Two changes to keep that from
happening again:

1. Wrap both harness invocations with `timeout` (60s Neovim, 30s
   Vim). A misbehaving LSP attach, a stuck `vim.defer_fn`, or
   ex-mode hung on stdin can no longer hold the runner indefinitely;
   `timeout` kills the process and the wrapper exits non-zero so CI
   shows the real failure shape.

2. `</dev/null` on `vim -e -s` so ex-mode doesn't sit waiting for
   input on CI's non-TTY stdin (the local zsh run inherits the
   user's tty, masking this).

3. CI: the keymaps job now has `needs: test` and
   `timeout-minutes: 10`. `needs: test` serialises behind the cargo
   jobs so we don't fight for the single Gitea runner, and the
   workflow-level timeout is a belt to the script-level `timeout`'s
   braces — if for some reason both fail the same way, the runner
   reclaims itself in 10 minutes instead of 30.

Local timing: `test-keymaps.sh` 10.4s, `test-keymaps-vim.sh` 0.1s.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.gitea/workflows/ci.yaml

@@ -59,6 +59,11 @@ jobs:
   keymaps:
     name: editor keymaps
     runs-on: ubuntu-latest
+    # Serialise behind the cargo jobs so we never compete with them
+    # for runners, and inherit their warm cargo cache instead of
+    # forcing a release build of our own.
+    needs: test
+    timeout-minutes: 10
     steps:
       - uses: actions/checkout@v4
       - uses: dtolnay/rust-toolchain@1.83