feat(self-hosting): replace placeholder collection handles

[graydeon]

Summary

The self-hosted compiler still relies on placeholder handle-based collection abstractions across the lexer, parser, and query layers.

That workaround has enabled progress, but it is now load-bearing enough that it risks spreading across more self-hosted subsystems and making later cleanup harder.

Why this matters

• collection-building is central to lexer/parser/query behavior
• placeholder handles are workable for bootstrapping, but expensive if they leak into long-term interfaces
• self-hosting progress will be easier to maintain if temporary representations have explicit replacement boundaries

Current behavior

The self-hosted compiler tree still contains placeholder sequence/list representations and dummy return paths in multiple modules, including lexer/query/parser-related code.

Expected behavior

• the self-hosted compiler should converge on one bounded temporary sequence abstraction or a real collection implementation
• replacement boundaries should be explicit so later self-hosted passes do not depend on ad hoc handle semantics

Suggested scope

• choose one sequence representation for the current self-hosted milestone
• document where it is allowed to appear and where it must not leak
• update the current self-hosted lexer/parser/query surfaces to use that single approach consistently
• add focused tests around the chosen representation

Acceptance criteria

• one collection strategy is used consistently for the current self-hosted milestone
• lexer/parser/query code no longer use multiple ad hoc placeholder patterns
• tests cover the chosen representation well enough to support future replacement