PR 3 — Option B flow-sensitive narrowing (conservative and correct)

Goal: Make the AP242 pattern work without rewriting schemas, by narrowing SELECT variables in the RHS of an AND when guarded by ('' IN TYPEOF(var)).

This PR must avoid the earlier concerns: no OR/NOT leakage, robust TYPEOF detection, robust string literal detection, no huge ABI churn if possible.
Agent input

Implement flow-sensitive narrowing with these strict rules:

Only apply narrowing for AND:

For expression A AND B, resolve A normally.
Collect refinements from A only from conjuncts that are guaranteed true if B executes.
    Implement collect_refinements_from_conjunction(A):
        if node is AND(x,y): recurse into both
        else if node matches predicate pattern: extract refinement
        else: do not recurse further
    Do not collect refinements from subexpressions under OR, NOT, function calls, etc.

Refinement predicate pattern (minimum viable):

Match ('<TypeNameString>' IN TYPEOF(<identifier>))
Make matching robust based on actual AST:
    Do not rely on expr->symbol.name == "TYPEOF" unless that is confirmed correct.
    Use the same resolved builtin object / token kind TYPEOF uses in this codebase.
    Ensure string literal detection uses the literal node kind, not “has string type”.

Type safety:

Only refine if the variable’s static type is a SELECT and the target type is a member (directly or via nested SELECT).
Type name lookup must support schema-qualified names in the string literal:
    'SCHEMA.TYPE' → try TYPE in current schema if full lookup fails
    case-insensitivity is ok but be careful not to hide errors; use normalization rather than “guessing”.

Application:

When resolving an identifier expression for that variable inside B, use the refined type for return_type.
Scope:
    refinements apply only while resolving B (RHS of that AND)
    nested ANDs inside B should inherit refinements (since they are still in the RHS execution path)

Implementation approach:

Prefer minimal invasive changes:
    If feasible, don’t change every operator resolver signature.
    Special-case OP_AND in EXP_resolve or wherever operator dispatch happens, passing a context into recursive resolves only where needed.

Tests:

Add a small schema that mirrors AP242:
    TYPE set_representation_item = SET OF INTEGER;
    TYPE target = SELECT(set_representation_item, INTEGER);
    ENTITY e; item: target; WHERE wr: ('SET_REPRESENTATION_ITEM' IN TYPEOF(item)) AND SIZEOF(QUERY(x <* item | x > 0)) >= 0; END_ENTITY;
Add a nested AND test to ensure refinements flow into nested RHS.
Do not add “must fail” tests unless the harness supports them.

Acceptance criteria:

data/ap242/242_mim_lf.exp parses/resolves past styled_item without PE056.
No new acceptance of QUERY-on-SELECT without a guard/cast.
No refinement applied under OR guards.