Flask adapter diverges from the engine request/response flow used by fastapi-guard #39

Summary

I audited the Flask adapter against fastapi-guard, the reference adapter, and found it diverges from the engine request and response flow.

• _check_passthrough skips the whole pipeline when the request has no client host. The engine BypassHandler.handle_passthrough returns the fail_secure 403 in that case, and fastapi-guard returns it.
• The route all-checks bypass is reimplemented in the adapter. It never uses BypassHandler.handle_security_bypass, so the real view is not called through the engine and the response modifier path differs.
• _after_request runs for every response, including ones returned from before_request (blocked, CORS preflight, bypass, init failure). Those responses emit request metrics and get the pass-through response pass, which fastapi-guard never does.
• Global behavior return rules (global_behavior_rules) are never passed to the engine response pass, so they never fire.

Expected

Route through the engine exactly where fastapi-guard does: engine passthrough handler, engine security bypass handler, and the response pass only for responses that came out of the view, with global return rules wired in.