Fix real-world OPY receiver/member call compatibility (`eventPlayer.setMoveSpeed` and peers)

[Teakowa]

Discovered by: wrightkit/agent-lab#68

Goal

Fix a real-world .opy frontend compatibility bug where receiver/member calls that fall within Wright's declared supported surface can fail before semantic lowering.

This issue is specifically about receiver/member call parsing/resolution such as eventPlayer.setMoveSpeed(...). Builtin enum/catalog coverage is tracked separately in #105 because it is a data/compatibility-surface problem with different implementation and acceptance criteria.

Context

The current OPY support matrix already declares receiver/member forms such as:

• eventPlayer.member -> player-variable/member resolution or receiver call on EventPlayer;
• variable receivers -> ReceiverCall / Index;
• dotted member/call syntax as part of the supported expression surface.

The parser also has an explicit postfix . -> Expr::Member -> call -> Expr::ReceiverCall path. Therefore a reproducible parse failure on a normal supported receiver call is not merely undocumented syntax: it is a correctness gap inside an already-declared compatibility surface.

Repro

rule "member access":
    @Event eachPlayer
    @Condition eventPlayer.isAlive() == true

    eventPlayer.setMoveSpeed(100)

Wright v0.1.0:

wright check member.opy -f json

produces a frontend parse error similar to:

expected a member name after '.'

at the setMoveSpeed call.

Scope

• Reproduce the failure against the current native .opy frontend.
• Identify whether the break is in lexing, postfix/member parsing, receiver-call construction, name classification, resolution/lowering, or a combination.
• Fix the general receiver/member call path rather than special-casing setMoveSpeed.
• Audit nearby real-world forms that use the same grammar/semantic path, especially:
  • eventPlayer.<builtin>(...);
  • other player/value receivers with builtin methods;
  • member access followed by call arguments;
  • supported member expressions used in conditions and actions.
• Add focused parser/lowering tests plus at least one real-project/corpus regression derived from agent-lab/Bastion evidence.
• Ensure unsupported member forms still fail with deterministic structured diagnostics rather than being accepted accidentally.
• Update the OPY support matrix only if the actual supported boundary changes or needs clarification.

Non-goals

• Adding arbitrary Wright-only OPY syntax.
• Broadly implementing every OverPy member/builtin without evidence.
• Adding missing builtin enum members; Add corpus-backed OPY builtin enum coverage for ChaseTimeReeval.NONE and nearby real-world gaps #105 owns that work.
• Solving unrelated deferred syntax such as dict literals, postfix ++, line continuation, or named arguments.

Acceptance criteria

• The repro using eventPlayer.setMoveSpeed(100) passes the native frontend through the declared supported workflow.
• Existing supported receiver/member forms continue to work.
• The fix is general to the affected parser/resolver path and is not a one-off string/name exception.
• At least one real-consumer/corpus fixture guards the regression.
• Unsupported member forms retain structured, source-located diagnostics.
• Current OPY differential/frontend regression suites and CI are green.

Relationships

• Real-consumer discovery: wrightkit/agent-lab#68.
• Split enum/catalog coverage into Add corpus-backed OPY builtin enum coverage for ChaseTimeReeval.NONE and nearby real-world gaps #105.
• This is a focused compatibility correctness fix justified by a real consumer blocker, not broad syntax expansion for coverage metrics.