Metadata: declare Lynxtron requirement via package.json → example-metadata.json

Background

go-web PR #61 adds an "Open in ..." panel that reads a new top-level field on example-metadata.json:

{
  "name": "examples/cool-3d-demo",
  "version": "0.2.5",
  "reactLynxVersion": "0.120.0",
  "nativeFramework": "lynxtron",   // ← new, optional
  "templateFiles": [
    { "name": "main", "file": "dist/main.lynx.bundle" }
  ]
}

Semantics: nativeFramework declares which native framework this bundle requires at runtime. Absent = no dependency, universally compatible with any Lynx-compatible host (Lynx Explorer, Lynxtron Go, Sparkling, ...). Present = only that host can execute the bundle; go-web hides the "scan QR with Lynx Explorer" tab and only surfaces the corresponding deep-link entry.

This is distinct from build-time framework versions (reactLynxVersion, vueLynxVersion) — those describe how the source was compiled and are already baked into the bundle. nativeFramework describes what the host must provide.

Where the field should come from

Today, example/scripts/prepare-examples.js generates example-metadata.json by scanning the npm tarball for *.lynx.bundle files. It does not read anything Lynxtron-specific.

Proposal — declare the field in the example package's own package.json:

// packages/cool-3d-demo/package.json
{
  "name": "@lynxtron-example/cool-3d-demo",
  "version": "0.2.5",
  "go": {
    "nativeFramework": "lynxtron"
  }
}

Then update prepare-examples.js to lift pkg.go?.nativeFramework into the generated metadata (see PR #61 for the consumer side).

Ask

• Agree on the field name and location (pkg.go.nativeFramework vs. some other convention).
• Decide whether every Lynxtron example package should set it explicitly, or whether the field can be inferred (e.g. from the @lynxtron-example/* scope).
• Update the example package template / publishing docs so authors set it as they publish.

Happy to open the corresponding PR on prepare-examples.js once we agree.

/cc @huxpro

Start with example/scripts/prepare-examples.js and inspect how it scans npm tarballs into example-metadata.json. Review the example package template and publishing documentation, then resolve the proposed pkg.go.nativeFramework convention and whether inference is needed. Done means the agreed metadata field is propagated and author guidance is updated.