Fix: read hook payloads over 1 MiB instead of dropping them

[aayank13]

Fixes #154

The hook read at most 1 MiB of stdin. Anything longer was cut off in the middle of a JSON string, failed to parse, and the whole event was dropped. Piping a 1.1 MB UserPromptSubmit payload into trodden hook claude-code printed nothing and logged parse the hook payload: EOF while parsing a string at line 1 column 1048576. The same happened to tool payloads from agents learned through hooks: a Cursor postToolUse for cargo test with about 1.5 MB of output never reached the session journal, so if that run was the passing check the task looked unverified.

The hook now reads the whole payload. A cap only turns a big payload into a lost one, and the payload comes from the agent on the same machine, so there is nothing to defend against. Reading to the end also drains stdin, so the agent never blocks on a full pipe. I considered a streaming parser that skips the large fields, but every harness parses its own payload shape, and the extra memory for a few megabytes of JSON held for the length of one hook call does not justify that complexity. The read moves into a small read_payload method that takes any reader, so it can be tested without a real stdin.

To test it, I built the binary with a scratch TRODDEN_HOME and piped in a 1.1 MB Claude Code prompt and a 1.5 MB Cursor shell payload. Before the change both logged the EOF error above and the Cursor journal was never written. After it, the error log stays empty and the Cursor run is journaled as a succeeded cargo test. A new unit test reads a 3 MiB prompt payload through read_payload and checks it arrives whole and parses into a prompt event. It fails with the old cap in place.