fix(middleware): apply the custom response modifier and refresh stale docs

[rennf93]

Closes #40

I wired Engine.ModifyResponse into the pass-through path in the order the reference applies it (security headers, CORS, modifier, then CORS again). The status was already observed correctly. I also removed the stale examples and docs claims that the default address headers need a manual ExcludedDetectionHeaders entry and that EnableAgent fails validation; I verified both against the current engine, with a test pinning the header claim.

With a modifier configured the adapter holds the whole handler response in memory until the handler returns, so streamed responses are delivered at the end. Without a modifier nothing changes. Hijacked connections are left alone. I added real-framework tests that fail on master (modifier ignored, modifier not seeing CORS, wrong status) and pass now, and the repo gate is green: gofmt, vet, staticcheck, unit and integration tests with Redis, and the 100% coverage gate. The engine API used (ModifyResponse) is already in the released v4.3.2 floor, so no dependency change.

prest-guard builds on this adapter, so it picks the modifier up once this is released. I did not change the unknown-client-address behavior: the reference answers 403 "Client address could not be determined" under fail_secure in handle_passthrough, but Engine.Check in guard-core-go has no such step (only GuardWebSocket does), so that fix belongs in the engine.