Complete the OverPy builtin, member, enum, and alias surface

[Teakowa]

Parent: #88

Goal

Complete the pinned OverPy builtin semantic overlay as one audited language capability, covering actions, values, member functions, enums/constants, aliases, receiver domains, and source signatures without implementing individual names as separate roadmap items.

Context

Recent corpus work exposed isolated names such as createDummy, hudSubtext, and horizontalAngleOfDirection. These are evidence that the builtin inventory/consumption path is incomplete; they should not become one-issue-per-name execution.

Canonical Workshop actions, values, enums, and members remain owned by workshop-rs. opy-rs owns the OverPy source identities, aliases, signatures, receiver syntax/categories, and mapping into canonical identities.

Scope

• Audit the complete pinned OverPy builtin/value/member/enum/constant/alias source inventory used by the declared compatibility target.
• Complete OPY source identity, alias, arity/keyword/signature, receiver-domain, enum/member, and action-vs-value semantics for that inventory.
• Map supported OPY identities to canonical workshop-rs contracts without copying canonical Workshop data into opy-rs.
• Preserve structured diagnostics and source provenance for unknown names, invalid domains, arity errors, and position errors.
• Validate the category against generated/inventory-backed probes and representative real-project usage.

Non-goals

• One issue or PR per builtin/member/enum name.
• Duplicating canonical Workshop catalogs or gameplay semantics.
• Workshop optimizer/output identity.
• Project-specific aliases or WrightKit-only OPY extensions.

Acceptance criteria

• The declared pinned OverPy builtin/member/enum/alias inventory is auditable and executable rather than inferred from corpus first failures.
• Every in-scope source identity has the expected OPY-level signature/category/alias semantics and a correctly owned canonical mapping or explicit external owner blocker.
• Representative positive and negative coverage validates receiver, arity, keyword, alias, enum/member, and action/value-position behavior.
• Real-project corpus execution no longer exposes an unowned builtin/member/enum identity inside the declared compatibility target.
• Canonical Workshop semantics remain sourced from workshop-rs.

Relationships

This workstream subsumes narrow builtin execution issues such as #132; their minimized and real-project evidence remains regression input for this category.

PR budget

Target: 1 implementation PR. Maximum: 2 non-release PRs. Split only by coherent inventory/semantic boundaries, never by individual builtin name.