perf: faster app startup

[bajrangCoder]

Replaces #2930 and #2931, which merged early and are reverted in #2933. This PR is based on revert-startup-perf so the diff shows all of the startup work. Merge #2933 first; this PR then retargets to main.

Summary

Startup work that keeps app and plugin behaviour unchanged. Measured on a Moto Edge 40 Neo, production build:

• main.js: 3,313 KB → 1,997 KB (−40%), so there's less to parse before anything runs.
• Editor visible: ~1.6–1.8 s after the page starts loading.
• Time from the splash hiding to all plugins being loaded: ~3.4 s → ~1.5 s. Plugin loading also uses far less main-thread CPU, so the UI responds sooner after the splash.

Changes

Startup sequence (src/main.js)

• No fixed 500 ms splash delay. The splash hides once the app has rendered a frame. Plugins, login check and ads still run afterwards, in the same order.
• Parallel native calls. Encodings, storage folders, install source and Android version are requested together instead of one after another.
• Play Billing check runs alongside startup.
  • It starts at deviceready instead of blocking it.
  • On free builds, plugins (theme plugins included) still wait for it, so they initialize with the settled Pro status.
  • Non-Pro users also wait for it before the UI is usable, because restoreTheme() resets and saves a paid theme when a dialog closes while HAS_PRO is false.
  • Paid builds are always Pro and never wait.
  • Ads and the login check still run after the purchase result. A found purchase is cached.
• Native splash fade: 500 ms → 150 ms (config.xml).

Smaller main.js

• Terminal (xterm and add-ons) loads on demand through components/terminal/loader.js.
  • xterm.css stays in main.css.
  • The module is loaded before plugins, so the synchronous plugin terminal APIs behave as before.
  • Modules that only need theme data or defaults import the small terminal modules that don't pull in xterm.
• Run/preview (lib/run) loads on first use. It pulls in markdown-it, its plugins and the markdown preview. runLazily captures the requested file first.
• mime-types loads on demand at each lookup site (utils/mimeTypes.js).
• Built-in editor themes skip the load-time check. They are still validated when applied; plugin themes are still validated when registered.
• Build target is WebView 67+ (the app's minimum) instead of ES2015. core-js uses swc entry mode, so it includes only the polyfills that WebView needs, and every global a plugin could rely on is still present.

Native startup

• Encodings are cached. The Android charset list is cached in localStorage, keyed by app version, Android version and device model, so the native call runs only when one of those changes.
• Sidebar apps: the four built-in sidebar app chunks load in parallel and are added in their original order.

Command registration (found by profiling on the device)

Every command registration, including each plugin addCommand, rebuilt the whole keymap. Each rebuild compared every binding with every other one and re-parsed both key strings on each comparison, then reconfigured every editor pane. That was ~1.8 s of main-thread CPU while plugins loaded.

• Cached key parsing. Canonical key strings are cached; the cache is capped at 1,000 entries.
• No map copies. The conflict check finds the first conflicting binding without copying the claimed-keys map for every candidate.
• Rebuild on read. The keymap is rebuilt when next read instead of on every registration, so reads are always current. The command object registerExternalCommand returns still has its final key and description immediately.
• One editor update per burst. Keymap refreshes are applied once per burst in a microtask, which runs before the next key event.

Existing bugs fixed along the way

• disabledMap was out of scope in the owned plugins list and crashed it when billing is available.
• Cancelling the sponsor form caused an unhandled rejection.

Review feedback from #2930 and #2931

• Plugins seeing a stale Pro status: fixed, plugins wait for the purchase check on free builds.
• Terminal chunk awaited before plugins: kept on purpose. The chunk is fetched on every launch to restore terminal sessions, and waiting keeps the synchronous plugin terminal API unchanged. Measured cost: ~40 ms before plugins start.
• Wrong file could run during the first load of the runner: fixed, the file is captured before loading.
• Key cache could grow without limit: fixed, the cache is capped.

Not included

• Restoring only the active tab. Implemented and measured, then dropped: no gain on the test device, and it carried risk.
• Lazy-loading Emmet. It's the largest remaining part of main.js, but it's wired synchronously into editor creation. Left for a separate change.

Testing

• vitest run: 728/728 passing. New tests: commandRegistryKeymap.test.js (batched keymap updates, current reads, removal, conflicts) and runLazily.test.js (runs the requested file after a tab switch).
• Production build checked: xterm is not in main.js, and its styles are still in main.css.
• Startup timings were measured on the device with temporary marks, which are not part of this PR.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 2/5

The PR is not ready to merge until purchase revocation and an unbounded billing startup wait are addressed.

Summary

The PR shortens startup by deferring large modules, parallelizing native initialization, caching encodings, and batching command-keymap work.

• The new purchase cache can restore revoked Pro access on an offline launch.
• Making the unbounded billing check a startup prerequisite can leave free-build users on the splash screen.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Device ready] --> B[Start purchase check]
  A --> C[Initialize native services]
  C --> D[Build workspace]
  B --> E[Wait for Pro status]
  D --> E
  E --> F[Load theme plugins and restore files]
  F --> G[Reveal app]
  G --> H[Load regular plugins, then login and ads]

Loading

_{Reviews (1) · Last reviewed commit: "fix: run the requested file and bound th..."}

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•   Revoked Pro Access Returns Offline src/main.js:477 ▶

  A confirmed purchase is now saved as acode_pro, but a later check that finds no purchase does not clear it. After a refund or revocation, an online launch can remove Pro access for that session, yet the next offline launch reads the stale value and skips verification. Paid themes and icons become available again, and ads are suppressed. Clear the stored entitlement when verification finds no purchase.

  How this was verified: Startup reads the stored Pro flag before checking purchases, and the offline return bypasses the only branch that can downgrade it.

•  Billing Can Block Startup src/main.js:814 ▶

  Free-build startup now waits for Play Billing before loading theme plugins, and the splash also waits for the check when the user is not Pro. If iap.startConnection or iap.getPurchases never calls back, neither wait has a timeout, so the app remains on the loading screen indefinitely. Previously, the purchase check ran after the workspace was revealed. Give this startup wait a bounded fallback.