feat(api-security): add effective method and route normalization gates

[RanuK12]

Closes #1283.

Summary

Adds Step 1A: Effective Method and Route Normalization to the API security review workflow, covering the full scope of issue #1283:

What this PR adds

1. Item 8 to Step 1 — Capture effective method and route handling during API inventory (reverse proxy rewrites, method override headers, encoded slashes, gateway-to-application route differences).

2. Step 1A: Effective Method and Route Normalization — A dedicated gate between inventory and findings, with:

   • 5 categories of what to look for (method override, gateway rewrites, normalization, OpenAPI drift, authorization placement)
   • 4 vulnerable HTTP examples (method override, proxy rewrite, encoded slash, duplicate slash)
   • 1 benign YAML example (safe gateway/app config) for false positive calibration
   • Detection grep patterns covering JS/TS/Python/Go/Java/C#/Ruby/PHP/Config
   • Framework-specific guidance table (Spring Boot, Express, Django, ASP.NET, Go, nginx)
   • Severity criteria table mapping conditions to API1/API5/API8/API9
   • 7-item normalization verification checklist
   • Closing gate: authorization evidence must cover both gateway and application layers

3. Updated API5 reference table entry — Now mentions "rewritten routes and method overrides."

4. Common Pitfalls intel: appsec community updates 2026-03-29 #7 — Pre-rewrite vs. effective request authorization bypass.

5. New references — OWASP API5:2023 and RFC 9110 HTTP Semantics.

Coverage vs. issue requirements

Issue Requirement	Covered?	Where
Effective post-rewrite method/path evidence	✅	Step 1A gate + verification checklist
Method override discovery and authorization checks	✅	Step 1A "What to look for" + vulnerable examples + grep patterns
Proxy/gateway/app route normalization consistency	✅	Step 1A examples + framework table + severity criteria
OpenAPI-vs-code method drift	✅	Step 1A "What to look for" + severity table
Detection hints (X-HTTP-Method-Override, etc.)	✅	Grep patterns + framework table
405 Method Not Allowed evidence	✅	Severity criteria + checklist item
Mapped to API1/API5/API8/API9	✅	Severity criteria table + reference table update
False positive calibration (benign example)	✅	Benign YAML example with explanation
RFC 9110 reference	✅	References section

Validation

• ✅ Markdown fence balance: 20 fences (even)
• ✅ All required markers present (Step 1A, X-HTTP-Method-Override, UseHttpMethodOverride, HiddenHttpMethodFilter, encoded slash, 405, pre-rewrite, RFC 9110)
• ✅ 114 additions, 1 deletion — surgical change to one file
• ✅ Follows repo style: markdown with frontmatter, consistent section formatting, existing OWASP mapping patterns
• ✅ No new files, no breaking changes, no prompt injection vectors

Why this is better than a minimal fix

This PR provides a complete methodology (not just a checklist) that a reviewer can follow step-by-step. The framework table, grep patterns, and verification checklist make it actionable for real codebases. The benign example explicitly helps reviewers avoid false positives on well-configured gateway setups.

[RanuK12]

/claim #1283