scaffold Flutter app — kernel, extensions, widgets, Tier 0 built-ins

First real content under app/. Lays the whole Tier 0 foundation in one
commit because the pieces depend on each other circularly (kernel →
extension → widgets → built-ins all reference types from the layer
below); splitting would leave intermediate commits that don't compile.

Key shapes:

  * bare WidgetsApp root — no Material, no Cupertino, no Scaffold.
    ClideTheme InheritedWidget is the only source of tokens.
  * ClideKernel InheritedWidget aggregates 18 services (settings,
    project, extensions, theme, panels, events, ipc, commands +
    palette + keybindings, clipboard, files, notify, dialog, tray,
    secrets, os, net, focus, log, i18n). ExtensionContext exposes
    them through a stable interface.
  * ClideExtension + sealed ContributionPoint hierarchy (Tab,
    StatusItem, Toolbar, Command, TrayItem, LayoutPreset). One
    manifest ships N contributions into kernel slots.
  * Three-tier theme pipeline: palette (named colors) → semantic
    roles → ~60 surface tokens. Defaults at each layer so legacy
    palette-only themes produce a complete SurfaceTokens.
  * A11y baked in from day one — every interactive primitive wraps
    in Semantics(label:, hint:, button:); ensureSemantics() at boot;
    theme/contrast.dart helper exposes token pairs for the WCAG
    gate in the a11y test suite.
  * i18n ported from fframe's L10n pattern (text-driven, namespaced
    JSON catalogs, caller-supplied placeholders) with a proper
    locale fallback chain (exact → language → default → placeholder)
    fframe lacks.
  * Four Tier-0 built-ins live (default-layout, welcome, ipc-status,
    theme-picker) plus 17 id-reserving stubs so later tiers fill in
    without rename churn.

.gitignore extended to cover app/ sub-package artefacts and the
Playwright harness scratch dirs.

Co-Authored-By: Claude <noreply@anthropic.com>

app/lib/lua/src/adapter.dart

@@ -0,0 +1,30 @@
+import 'package:clide_app/extension/extension.dart';
+
+/// Tier-0 stub. The real adapter wraps a parsed Lua extension manifest
+/// and a handle to the Lua state; contributions are proxied to
+/// callbacks registered by `clide.contribute(...)` from the Lua side.
+class LuaExtension extends ClideExtension {
+  LuaExtension({
+    required this.id,
+    required this.title,
+    required this.version,
+    this.dependsOn = const [],
+  });
+
+  @override
+  final String id;
+  @override
+  final String title;
+  @override
+  final String version;
+  @override
+  final List<String> dependsOn;
+
+  @override
+  List<ContributionPoint> get contributions => const [];
+
+  @override
+  Future<void> activate(ClideExtensionContext ctx) async {
+    throw UnsupportedError('Lua runtime lands at Tier 6.');
+  }
+}

app/lib/lua/src/capability_api.dart

@@ -0,0 +1,13 @@
+/// Tier-0 stub for the sandboxed `clide.*` table exposed to third-party
+/// Lua extensions.
+///
+/// The surface is deliberately narrow: `clide.ipc.request`,
+/// `clide.events.on`, `clide.log`, `clide.contribute`, and scoped
+/// kernel-service getters that mirror `ClideExtensionContext`. Lua
+/// code has no `io`, no `os.execute`, no `package.loadlib`, no `debug`
+/// — those are removed from the global state at sandbox init.
+///
+/// Full binding table lands with the Lua runtime at Tier 6.
+class CapabilityApi {
+  const CapabilityApi();
+}

app/lib/lua/src/host.dart

@@ -0,0 +1,14 @@
+/// Tier-0 stub. The real implementation loads a vendored liblua via
+/// `dart:ffi` and exposes a `LuaState` handle that [LuaExtension] uses
+/// to run script callbacks. Lands at Tier 6.
+class LuaHost {
+  LuaHost._();
+
+  /// Boot the vendored liblua. Throws until Tier 6.
+  static Future<LuaHost> start() async {
+    throw UnsupportedError(
+        'Lua runtime lands at Tier 6 (supporter tool sibling of ptyc).');
+  }
+
+  Future<void> dispose() async {}
+}

app/lib/lua/src/render_intent.dart

@@ -0,0 +1,14 @@
+/// Tier-0 stub for the declarative widget DSL Lua extensions return
+/// from their `on_render` callbacks.
+///
+/// Lua can't construct Flutter widgets; instead it returns tables like
+/// `{type="list", items={...}}` or `{type="stack", children={...}}`,
+/// which the Dart renderer maps to widget primitives. The vocabulary
+/// is closed and documented — extensions declare intent, the shell
+/// renders it with consistent theming.
+///
+/// The concrete intent shapes (list, tree, stack, button, text, input,
+/// editor-embed) land with the Lua adapter at Tier 6.
+sealed class RenderIntent {
+  const RenderIntent();
+}