AOT: support text-asset imports (import x from './f.txt'/.sql/.md) — inline contents as a string instead of parsing as TypeScript #5223

Context: next wall after #5206 + #5214 + #5216, compiling opencode's real source.

Problem

import X from "./file.txt" (a text-asset import) makes perry try to parse the .txt as TypeScript and fail:

Error: Failed to parse .../plugin/command/initialize.txt: Parse error ...

from import PROMPT_INITIALIZE from "./command/initialize.txt". This is pervasive — opencode alone has 36 .txt + 44 .sql + 1 .md text-asset imports (bundler "text"/"raw" loaders), plus 2 .wasm.

Proposal

Treat recognized non-code asset imports as text loaders: read the file's contents and synthesize a module whose default export is the file contents as a string, instead of parsing it as TS. Mirror the existing JSON-module path in crates/perry/src/commands/compile/collect_modules.rs (~L475, "Failed to parse JSON module") — which already special-cases an extension before the TS parse (~L543-562) and builds a synthetic module from a non-TS file.

Trigger on either:

• a recognized text extension: .txt, .sql, .md, .html, .css, .graphql/.gql, .glsl (sensible default set), and/or
• an explicit import attribute with { type: "text" } (the parser already enables import_attributes; AST carries it).

Result: import s from "./x.txt" binds s to the string contents; import s, ... default works. Resolution already succeeds (the explicit .txt path resolves as a file) — only the parse step needs the text branch.

Scope: text → string. .wasm is a separate concern (bytes / WebAssembly.Module) — out of scope here; note it.

Why

Bundler text/raw loaders are ubiquitous in real apps (prompts, SQL, templates). A bundler pre-pass inlines these for free, but supporting them directly lets perry compile such source as-is. Advances the opencode wall chain: new Function ✅ → @/ aliases ✅ → require() builtins ✅ → text-asset imports (this) → …