[doronz88]

Two changes to how traces are filtered by process (filter_process, parse-live --process):

Drop other processes' kevents before parsing. filter_process was applied after TracesParser had built every trace, so it saved only the formatting. _filter_kevents now drops each kevent whose thread is known to belong to another process before it is parsed. Threads whose process isn't known yet still go through, and the existing filter on finished traces still runs last. Some events pass whatever their thread:

• DBG_TRACE is needed to learn threads, processes, names and strings, and passes as before.
• Disk I/O (DBG_DKRW) completes on whatever thread the completion interrupted, and is paired with its issue by buf address.
• A kperf sample (DBG_PERF) can assign its own thread to a different process (PERF_THD_Data).
• During execve, mac_execve and posix_spawn (with POSIX_SPAWN_SETEXEC), the calling thread's process changes.

Give kernel_task's threads pid 0. xnu marks threadmap entries valid with their pid, and kernel_task's with 1 (_resolve_kernel_task in bsd/kern/kdebug.c). That collides with launchd's pid. So kernel threads were attributed to launchd, and --process kernel_task showed almost nothing.

Verification

• Unit tests for the early drop, cross-thread disk I/O, exec, and kernel_task's threadmap entries. Each new test fails without its change.
• Compared on a real iPhone 11 (iOS 27.2) unfiltered capture of 937k kevents. For every process name and pid in it (127 with kperf sampling, 126 without), the first commit's output is byte-identical to 1.9.0's and 2.0-2.5x faster (--process: 1.09s -> 0.53s with kperf, 0.98s -> 0.37s without).
• Effect of the second commit on the same capture without kperf: --process kernel_task goes from 30 to 88,899 lines and --process launchd from 92,568 to 3,699. Results with and without kperf now agree.