fix: keep collection scan alive when one entry errors (upstream #53)

User reported that running org-drill on a buffer with a new (no-ID)
entry threw 'Wrong Type Argument: hash-table-p, nil' and stopped the
scan — every subsequent entry was silently skipped, so the user had
to re-run org-drill once per item (10 items meant 10 invocations).

The exact source of the hash-table error is environment-dependent
(Emacs version, Org version, lazy org-id-locations init, Doom
overrides), so this fix targets the user-visible failure mode
instead of the underlying triggering condition.

Wrapped the per-entry body of org-drill-map-entry-function in
condition-case.  An error on one entry now logs a 'skipping' message
and the scan continues to the next entry.  The session collects all
the well-formed items, and the user can re-run drill once total to
process them — no more once-per-item.

Two regression tests: one verifies the resilience behavior directly
(fail entry 1, scan continues to entry 2), the other documents the
ID-creation-with-uninitialized-locations scenario as a smoke check.

0 files changed, 0 insertions, 0 deletions