Test the Settings session recording a named shortcut, key by key, and refusing when Accessibility is missing

## What happens

`Sources/UttrflowUX/SettingsSession.swift` has five public methods that have never run, and they are the ones the Settings window actually calls (`Sources/Uttrflow/Settings/SettingsViewModel.swift:51-88`):

- `beginRecordingShortcut(_ action:)` (lines 179-184), which starts recording for one row;
- `receive(_:)`, `hold(keyCode:modifiers:)` and `release()` (lines 80-94), which feed keys to the recorder and hand back settings to save;
- `rejectShortcut(_:)` (lines 74-76), which shows "Uttrflow needs Accessibility to read the keyboard."

`SettingsSessionTests` only uses the argument-less `beginRecordingShortcut()`, which records the dictation shortcut.

Measured on origin/main `26d7bc1` with `swift test --enable-code-coverage` (5,384 tests, all passing) and `xcrun llvm-cov export` over the test binary. The regions named below have an execution count of 0: no test runs them, so a change that breaks them passes `make verify`.

## Why it matters

Every shortcut row except Dictate goes through `beginRecordingShortcut(action)`. If it records onto the wrong action, or `release()` stops settling a held modifier (such as Fn alone), changing the clipboard or paste-last shortcut silently changes dictation instead, or saves nothing.

## How to reproduce

Run `swift test --enable-code-coverage`, then `xcrun llvm-cov show -instr-profile .build/debug/codecov/default.profdata .build/debug/UttrflowPackageTests.xctest/Contents/MacOS/UttrflowPackageTests Sources/UttrflowUX/SettingsSession.swift` and look for the `0` counts on the lines named above.

## Acceptance criteria

- `beginRecordingShortcut(.clipboard)`, then `receive` of a ⌃⌥V stroke, returns settings whose clipboard shortcut is ⌃⌥V and whose dictation shortcut is unchanged.
- `beginRecordingShortcut(.dictate)`, `hold(keyCode: 63, modifiers: [])`, then `release()`, returns settings with Fn held as dictation.
- `rejectShortcut("...")` sets the rejection the field shows, and the next successful change clears it.
- Each new test fails when the branch it covers is broken. Check this by hand before opening the PR: temporarily change the branch (flip the condition or return the other value), see the test fail, then restore it.

## Where to start

- `Tests/UttrflowUXTests/SettingsSessionTests.swift`, suite "An editing session". The test "records a new shortcut and hands it back to be saved" is the template.
- `Tests/UttrflowUXTests/SettingsShortcutTests.swift` shows how to build `KeyStroke` values.

Read `CONTRIBUTING.md` first. Iterate with `swift test --filter `, then run `make verify` before pushing. Only tests change; no product code needs to.

**Size:** S.

Read CONTRIBUTING.md first, then use Tests/UttrflowUXTests/SettingsSessionTests.swift and the existing “records a new shortcut and hands it back to be saved” test as a template. Consult Tests/UttrflowUXTests/SettingsShortcutTests.swift for KeyStroke values, run the focused suite with swift test --filter , and confirm the tests cover named recording, Fn release, rejection, and clearing before running make verify.

Written by the indexing model from the issue text.