fix: apply CustomResponseModifier, report the real response status and refresh stale docs #42

The engine exposes Engine.ModifyResponse and Config.CustomResponseModifier, and the reference applies the modifier to the pass-through response after the security headers and CORS headers, then injects CORS again (guard_core/core/responses/factory.py process_response, fastapi-guard dispatch). No adapter code calls ModifyResponse, so the modifier only ever runs on guard-generated responses and never on a response the application produced.

Separately, the status passed to Engine.ProcessResponse (request metrics and status: return rules) is read from c.Response().Status right after next(c). When the handler returns an error, Echo's HTTPErrorHandler has not run yet, so the engine records the unwritten default 200 for every echo.NewHTTPError(500) or plain error. I reproduced it with a global status:500 return rule that never trips.

The examples and docs/configuration.md still say the engine does not apply the default address-header exclusion and that EnableAgent fails config validation. Against the current engine, Host: 169.254.169.254 with X-Forwarded-For and Origin passes with penetration detection on and no ExcludedDetectionHeaders (the built-in DefaultExcludedHeaders covers them), and EnableAgent validates and degrades to agent-off without an AgentHandler (or fails NewEngine under AgentStrict).

Plan: run c.Error(err) before reading the status (the pattern Echo's own logger middleware uses), hold the response when a modifier is configured and run ModifyResponse last (CORS re-applied after it), and correct the examples and docs. Tests drive a real Echo instance, no engine mocking.