[Aikido] Fix IDOR protection bypass by validating tenant equality clause context

[aikido-autofix]

This patch addresses an IDOR (Insecure Direct Object Reference) protection bypass vulnerability where tenant equality checks were not validated for their SQL clause context. Attackers could bypass tenant isolation by placing tenant column equalities in non-filtering contexts such as SELECT projections or HAVING clauses. The fix adds clause context validation to lib/aikido/zen/idor/analysis_result.rb and lib/aikido/zen/idor/protector.rb, ensuring tenant equalities are only accepted when originating from WHERE clauses. This strengthens row-level security enforcement and prevents unauthorized data access across tenant boundaries.

✅ 1 issue fixed by this PR

Issue	Severity	Description
CodeAudit#811806040	HIGH	SelectVisitor::pre_visit_expr traverses expressions across a SELECT and records equality expressions without preserving whether they originated in a row-restricting WHERE clause, a projection, HAVING, JOIN condition, or a negated predicate. Protector#protect_filter then accepts any matching tenant column whose resolved value equals the request tenant ID. For example, with tenant ID 1 bound to $1, SELECT tenant_id = $1 AS same_tenant, users.* FROM users emits tenant equality metadata even though the equality is only a per-row projected boolean; it does not restrict the result set. The protector consequently allows the query, which can return rows belonging to every tenant. The demonstrated impact is a cross-tenant read; the supplied evidence does not independently establish mutation bypasses.

[codecov]

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
lib/aikido/zen/idor/protector.rb	0.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!