fix: Grant gdb ptrace capabilities so the end-to-end CI job passes

[Saggre]

Summary

The integration (end-to-end) CI job failed on master after #2 merged. The unit tests passed; the parser correctly extracted the shielded key and prekey. The failure was in the gdb unshield step:

warning: Error disabling address space randomization: Operation not permitted
decrypt.gdb:5: Error in sourced command file:
Couldn't write extended state status: Bad address.

Root cause

decrypt.gdb line 5 makes gdb call a function inside the live ssh-keygen inferior (getenv(...)). Performing an inferior call requires gdb to save and restore the process's extended CPU register state via ptrace(PTRACE_SETREGSET, NT_X86_XSTATE), and it also tries to disable ASLR. In run-test.sh the shieldbreak container ran without ptrace privileges, so on the GitHub runner's restricted seccomp/ptrace sandbox those calls were blocked.

This is why it was flaky: it worked where the host happened to allow the ptrace calls (local, and the earlier PR run) and failed where it did not (the master runner).

Fix

Run the extraction container with the standard "gdb in Docker" flags, --cap-add=SYS_PTRACE --security-opt seccomp=unconfined, in test/run-test.sh. The same flags are added to the documented docker run in the README and the example in entrypoint.sh, since any real use of the tool drives gdb the same way and needs them.

Testing

make test locally now passes with matching fingerprints and no Bad address error:

[*] Verifying the recovered key matches the original
    original  fingerprint: SHA256:9WOn...
    recovered fingerprint: SHA256:9WOn...
[+] PASS: recovered key is identical to the original

CI will confirm on the runner (the workflow now exists on master, so this PR triggers it).