Android: drop the orphaned page XMLs

[JumpLink]

Summary

Four Page XMLs under packages/app-android/app/views/main/ — editor.xml,
debugger.xml, game-console.xml, learn.xml — are dead code left over from
the pre-Adwaita Material shell. app/app-root.xml has defaultPage="views/main",
which resolves to the real page app/views/main.xml + its code-behind
app/views/main.ts; that file builds the four screens programmatically via
buildEditorScreen() / buildDebuggerScreen() / buildGameConsoleScreen() /
buildLearnScreen() and adds them as content views to the shell's
Adw.ViewStack. The four XMLs are never loaded as pages, and their sibling
.ts files don't even export the handlers the XML markup declares, so they
can't serve as code-behind either.

Per-file evidence

• editor.xml: declares onNavigatingTo, onNavigatingFrom,
  onHelpToggleTap — none exported by editor.ts. It also carries a
  hardcoded Quick Help text that already misled a prior review into treating
  it as the live source; the real content comes from QuickHelpView
  (app/mdx/quick-help-view.ts), sourced from packages/learn/quick-help.mdx
  via Builder.load({ path: "~/mdx", ... }), unrelated to this file.
• debugger.xml: declares onNavigatingTo, onNavigatingFrom — neither
  exported by debugger.ts, which only exports buildDebuggerScreen() and
  debuggerView.
• game-console.xml: declares onLoaded, onUnloaded, onNavigatingTo,
  onNavigatingFrom — none exported by game-console.ts, which only exports
  buildGameConsoleScreen(), gameConsoleView, gameConsoleController.
• learn.xml: declares onNavigatingTo, onNavigatingFrom — neither
  exported by learn.ts, which only exports buildLearnScreen() and
  learnView.
• learn.css: not referenced anywhere by name or class; it was only ever
  picked up implicitly through NativeScript's same-basename page-stylesheet
  convention with learn.xml, so it goes with it.

A repo-wide grep for each path/filename, for Builder.load/Frame.navigate
call sites, and for the four filenames in nativescript.config.ts,
vite.config.ts and package.json found nothing. w:SourceView and
mdx:TutorialView, the two widgets the dead XMLs also reference, stay: both
are real classes imported and used by the live editor.ts / learn.ts
screen builders too.

Validation

• gjsify install — first run in this worktree (no prior node_modules),
  ~14s, 1174 packages across 10 workspaces.
• gjsify format — clean, touched nothing besides intent.
• gjsify format --check — clean.
• gjsify build at the repo root fails on UNRESOLVED_ENTRY src/index.ts —
  a pre-existing mismatch (the root has no bundle entry point; the root
  build script is gjsify foreach --topological-dev build, not plain
  gjsify build), unrelated to this change.
• gjsify workspace @learn6502/app-android check reports 58 pre-existing
  TS2307 Cannot find module '@learn6502/core' errors — @learn6502/core
  has no dist/ yet in this fresh worktree. None of the errors reference the
  deleted files or their (non-existent) handlers.
• The real Android build path — ns build android (NativeScript CLI +
  Gradle, Android SDK present on this machine) — ran to completion: Vite
  transformed 660 modules with no errors, Gradle built successfully in ~48s,
  and produced platforms/android/app/build/outputs/apk/debug/app-debug.apk.
  This is the strongest available evidence that nothing references the
  deleted files.

Test plan

• Verified none of the four XMLs are loaded by path/string anywhere in
  app/, build configs, or bundler config
• Verified none of the declared handlers are exported by the sibling .ts
  files
• gjsify format / gjsify format --check clean
• ns build android produces a working debug APK with the files removed

🤖 Generated with Claude Code