docs: normalize the last target identifiers left in the verification record

The previous pass renamed the record directory but left two concrete identifiers in
the transcripts: a package name plus device serial in TOOL-VERDICTS.md, and a
logcat-truncated tag in FINDINGS.md. Both are now <PKG> / <DEVICE>, matching the
convention the extension-pass records already use. No claim, command or conclusion
changes -- only the identifiers.

docs/tool-verification/FINDINGS.md

@@ -172,7 +172,8 @@ The launch does show non-standard startup plumbing (observed):
   loader logging numeric status codes
 - `E Instrumentation: Uninitialized ActivityThread, likely app-created Instrumentation, disabling
   AppComponentFactory` — the process is not taking the ordinary `ActivityThread` path
-- `E m.tingfeng.too: Unknown bits set in runtime_flags: 0x40000000`
+- `E <PKG-truncated>: Unknown bits set in runtime_flags: 0x40000000` (logcat truncates the tag to 23
+  characters, so the package name appears clipped in this line)
 
 And yet the dex-side packer verdict is clean: no hardening library in the native set, an ordinary
 `application android:name` (the app's own class, not a packer stub), no known packer markers. Those two

docs/tool-verification/TOOL-VERDICTS.md

@@ -167,7 +167,7 @@ it is unfortunate that the scanner then violates that principle itself, one slot
 **Claim under test:** reads a live process's mapping table and reports which libraries are actually
 loaded, at what base, with what real architecture.
 
-**Run:** `--pkg com.tingfeng.tool --serial SSBYPJKFNVEU6PGA`, exit 0, 635 ms, pid 27064.
+**Run:** `--pkg <PKG> --serial <DEVICE>`, exit 0, 635 ms, pid 27064.
 Reported three actually-loaded app libraries — `libloader.so` (3 segments),
 `libsentry-android.so` (2), `libsentry.so` (3).