[parawanderer]

Takes the FindMy.py fix for the crash reported in #89, and keeps the diagnosis that found it.

What was wrong

service_keys_from_der converted a DerError into ServiceKeyError for the outer parse_one
and not for the descent that follows. _from_v1 opens with element.children(), so a payload
whose first element parses but whose contents are not DER raised a raw DerError — and the caller
in session.py only caught (ItemError, ServiceKeyError).

So the skip-and-continue written for exactly this case was bypassed on which exception type came
out. The proof is three consecutive lines of the reporter's log:

DEBUG  Item for acct 504353426f756e64 holds no key: … Truncated DER: claims 42, 30 remain
DEBUG  Item for acct 64656661756c74   holds no key: … Truncated DER: claims 67, 19 remain

DerError: Truncated DER: element claims 109 bytes, 61 remain      <- fatal

Those hex accounts are PCSBound and default. Two items failed the same way and were skipped
correctly; the third ended the export. One item in sixty-one.

What it actually cost

More than one item. unlock reads Manatee and then ProtectedCloudStorage, accumulating keys
across both, and the reporter's log shows Manatee completing with 141 elliptic-curve keys
before the crash. The exception unwound the whole call, so those were found and then discarded.

The fix

Upstream, acd17c5 → 47c4f89: the whole body of service_keys_from_der inside the guard rather
than only parse_one — both arms descend, so both could raise it — plus der.DerError alongside
ServiceKeyError in the caller that skips unreadable items. That second half is a consistency fix
rather than defensiveness: pcs.py's key walk already caught both, and _pcs_keys_in had not
carried it across.

Only python/uv.lock changes here.

Verified against the new pin

The #89 payload shape	DerError → ServiceKeyError, item skipped, run survives
A payload that already worked	still ServiceKeyError, no regression
Caller catches DerError	confirmed present in _pcs_keys_in
Exporter suite	441 pass, 2 skipped
flake8	clean

Reproduction, no account needed:

service_keys_from_der(bytes([0x30, 0x03, 0x02, 0x7F, 0x41]))
# before: DerError   after: ServiceKeyError

What is not claimed

This is not confirmed to fix the reported export, which is why it links #89 rather than closing
it. Whether the one fatal item was itself a key is not visible from the log — only the reporter's
next run answers that. What is certain is that the 61-item view now survives it, and the 141 keys
already recovered from Manatee are no longer thrown away.

If it still comes up short, the line to read is the holds no key DEBUG for the item that used to
be fatal.

Reported by @paula-coder-646 in #89, with a traceback that pinned the failure to the line.

---

PR description summarised by Claude Code.