Incorrect Authorization vulnerability in ash-project ash allows Authentication Bypass.

This issue affects ash: from 0.1.1 before 3.6.2.

Affected: Hex: ash

### Summary

When using **filter** authorization, two edge cases could cause the policy compiler/authorizer to generate a permissive filter:

1. **Bypass policies whose condition can never pass at runtime** were compiled as `OR(AND(condition, compiled_policies), NOT(condition))`. If the condition could never be true at runtime, the `NOT(condition)` branch evaluated truthy and the overall expression became permissive.

2. **Runtime policy scenarios that reduce to “no checks are applicable”** (an empty SAT scenario) were treated as an empty clause and dropped instead of being treated as **`false`**, which could again produce an overly broad (permissive) filter.

These bugs could allow reads to return records that should have been excluded by policy.

### Impact

Projects that rely on **filter-based authorization** and define:

* `bypass ... do ... end` blocks whose condition(s) are only resolvable at runtime and can never pass in a given request context, **or** * runtime checks that simplify to an **empty** scenario for a clause

may unintentionally generate a permissive query filter, potentially returning unauthorized data.

*Actions primarily affected:* reads guarded by filter policies. Non-filter (e.g., hard forbid) policies are not impacted.

### Technical details

This patch corrects two behaviors:

* **`Ash.Policy.Policy.compile_policy_expression/1`** now treats **bypass** blocks as `AND(condition_expression, compiled_policies)` instead of `OR(AND(...), NOT(con…