Guard --reissue against unknown CNs and leftover build files

Code review findings on the "skip revoke when .crt is missing" migration
path:

- CliRunner._issue() took the skip path whenever has_issued_cert() was
  False, which is also true for a typo'd/nonexistent CN — it would warn,
  skip the revoke, and go on to build, package, and email a brand-new
  certificate for a CN nobody asked to renew. The skip now only fires when
  the CN has a current index.txt entry (via _load_current_certs()); an
  unknown CN prints an error and exits 1 with nothing built. The TUI's
  _process_cert() doesn't need the same guard — renewal there always opens
  on an existing row (cn_readonly pins the CN), so a typo'd CN can't reach
  the branch.

- Skipping the revoke leaves pki/reqs/<CN>.req and pki/private/<CN>.key in
  place (normally revoke-issued archives both), which makes EasyRSA's
  build-client-full abort. Both CliRunner._issue() and
  CursesApp._process_cert() now check for those leftovers before building
  and fail fast with the exact paths, rather than surfacing EasyRSA's
  confusing error after the CA passphrase prompt. Neither path touches the
  files itself.

Also: strengthened two under-specified tests (test_main_rejects_bad_days_flag
now checks the resolver's message text, not just "--days", which also
appears in argparse's unrelated error; test_show_cert_form_confirm now pins
the Enter-keypress count so a partial "days" field reversion is caught), and
folded a malformed CLAUDE.md table row into its neighbor.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -31,8 +31,7 @@ Edit the `SETTINGS` block at the top of `openvpncertupdate.py` before first run.
 | `--revoke CN` | Revoke cert and regenerate CRL |
 | `--gen-crl` | Regenerate and copy CRL only |
 | `--list` | List recently-expired/soon-to-expire CNs (per `DAYS_PAST`/`DAYS_AHEAD`) with email; read-only, no CA passphrase needed |
-| `--list-all` | List all CNs with email; read-only, no CA passphrase needed |
-|  | Both grow a trailing `CERT` column marking `MISSING` CNs — see `CertInfo.has_cert_file`. The column is omitted entirely when every CN has its `.crt` |
+| `--list-all` | List all CNs with email; read-only, no CA passphrase needed. Both `--list`/`--list-all` grow a trailing `CERT` column marking `MISSING` CNs — see `CertInfo.has_cert_file`. The column is omitted entirely when every CN has its `.crt` |
 | `--email EMAIL` | Recipient address |
 | `--days N` | Certificate lifetime in days for `--create`/`--reissue`; overrides `CERT_DAYS` for that run |
 | `--send-email` | Force email delivery |
@@ -69,7 +68,7 @@ python3 -m pytest tests/test_pki.py::test_sorted_ascending -v  # single test
 
 ## Re-issue workflow
 
-0. `has_issued_cert()` gates steps 1–2: if `<PKI_DIR>/issued/<CN>.crt` is absent, both are **skipped** with a warning and the workflow goes straight to step 3. EasyRSA reads the serial out of the `.crt` itself, so `revoke-issued` can only fail on such a CN — and there is nothing to add to the CRL either. This happens when an `index.txt` is carried over from an older EasyRSA install without the `issued/` files: the index still lists V-status certs whose `.crt` never came along. `--revoke` / the TUI `r` key deliberately do *not* skip — an explicit revoke request should fail loudly rather than silently no-op. Such CNs are flagged before the user picks one: `_load_current_certs()` sets `CertInfo.has_cert_file` (one stat per CN, after the dedup), rendered as `(no cert)` before the email in the TUI list and as a `MISSING` cell in the `CERT` column of `--list`/`--list-all`
+0. `has_issued_cert()` gates steps 1–2: if `<PKI_DIR>/issued/<CN>.crt` is absent, both are **skipped** with a warning and the workflow goes straight to step 3. EasyRSA reads the serial out of the `.crt` itself, so `revoke-issued` can only fail on such a CN — and there is nothing to add to the CRL either. This happens when an `index.txt` is carried over from an older EasyRSA install without the `issued/` files: the index still lists V-status certs whose `.crt` never came along. `--revoke` / the TUI `r` key deliberately do *not* skip — an explicit revoke request should fail loudly rather than silently no-op. Such CNs are flagged before the user picks one: `_load_current_certs()` sets `CertInfo.has_cert_file` (one stat per CN, after the dedup), rendered as `(no cert)` before the email in the TUI list and as a `MISSING` cell in the `CERT` column of `--list`/`--list-all`. Two guards bound the skip so it can't silently do the wrong thing: (a) on the CLI, the skip only fires for a CN that `_load_current_certs()` actually knows about — a typo'd/nonexistent `--reissue CN` is *not* a migration gap and is rejected with `error: unknown CN ...` before anything is built (the TUI can't hit this: renewal always opens on an existing row, so the CN is never freeform there); (b) whichever entry point takes the skip, it first checks for leftover `pki/reqs/<CN>.req` / `pki/private/<CN>.key` — normally `revoke-issued` archives both into `pki/revoked/`, but skipping it leaves them in place, and EasyRSA's `build-client-full` aborts outright rather than overwrite them. Either leftover fails the workflow fast with the exact path(s), before the CA passphrase prompt — this tool never moves or deletes a private key itself
 1. `revoke-issued <CN>` — archives old key + CSR to `pki/revoked/`
 2. CRL regenerated and copied to `CRL_DEST_PATH` immediately after the revoke succeeds — the old cert is already revoked at this point, so the published CRL would otherwise be stale until a separate manual regen. Not fatal: a failure here is reported but the workflow continues to step 3 (a new cert is more urgent than a fresh CRL, and "Regenerate CRL" / `--gen-crl` remain available to retry)
 3. `build-client-full <CN> --passout=pass:<pw>` — generates new key + cert