Add a module-graph regression test for bridge typing (dsc#272 follow-up)

typeck/bridge_tests.rs only exercised check_program on a single file. compile_module_graph_with_options (dsc transpile / deka run's real path, also what dsc check uses once a project root is found) is a thin wrapper over the same check_module_graph_with_options — one function, not two — but that was asserted from reading the source, not proven by a test that actually goes through it with a bridge call in a dependency module.

graph_types_bridge_calls_in_an_imported_package puts a crypto-shaped sync bridge call and an fs-shaped async one in an imported module (mirroring ds_modules/@deka/fs imported by a consumer), and asserts the whole graph compiles. Fails on the pre-#272 shape with the exact diagnostics reported against a stale local build of this branch: "expected return type Result<bytes, string>, found type Result<<infer>, <infer>>" and "await expected Promise, found type Result<<infer>, <infer>>".

Verified: fails with check_bridge_call reverted to the old Result<Infer, Infer> sentinel (see PR body), passes on this branch.

Add import.meta: parsing, the frozen struct type, and client-graph rules

Implements rfd#12's ESM alignment amendment for the compiler side of import.meta (dsc#282):

• Parse import.meta as a meta-property (Expr::ImportMeta) in expression position. import(...) of a computed specifier keeps its own dedicated error rather than falling into a generic "expected expression" message.
• Type it as a frozen struct via the same primitive-member table that backs string/number/Array field access: url/dirname/filename: string, main: boolean, resolve(specifier: string): string. env is rejected with a message naming the zero-environment-variable rule; any other property is rejected with the list of what exists. Assignment to any property fails (import.meta is not an identifier or a field with a declared mutable owner, so the existing immutability check already covers it - no new logic needed there).
• The emitter never inlines a value: import.meta and every property access on it are written back out verbatim.
• In a client graph (dsc transpile --client / dsc bundle --client, and islands, which go through the same GraphCompileOptions.client path), dirname, filename and main are compile errors alongside the existing ui/server reachability check; url and resolve(...) stay legal since the browser (or the island hydration runtime) supplies them.
• Hover/.d.ds show the struct: Type::Named { name: "import.meta" } displays as its full field list instead of a bare name.

RFD interpretation: the RFD does not say whether import.meta bound to import at statement start should parse as an expression statement or fall into the import { ... } from "..." declaration grammar. Chose the former (peek for . after import at statement start) since JS treats import.meta as an ordinary expression wherever it appears, including as a bare statement.

Testing: every new test was run with its corresponding fix reverted and confirmed to fail first (parser: 10/10 new tests fail without the parser change; typeck: 6/9 fail without the primitive-member entries; module_graph: the dirname/filename/main rejection test fails without the client-graph walk, silently compiling instead; emit: the verbatim test fails when the emitted text is changed). See PR body for full command output.

cargo check --locked --workspace --all-targets is clean. Full cargo test --locked --workspace --no-fail-fast has two failures, both pre-existing on origin/main and unrelated to this change (confirmed by running them unmodified): deka-fmt's corpus_roundtrip test needs a testsuite-corpus checkout not present in this environment, and deka_compiler_wasm's tour ABI test needs .cache/tour fetched by scripts/ci-fetch-tour.sh.

Implement import type (rfd#12 ESM alignment amendment)

Parses import type { A, B } from "…" and the inline import { type A, b } from "…" form. Type-only bindings register normally for type positions (structs, enums, interfaces, aliases, opaques, newtypes) but not as a value: referencing one as a value (a call, a pipe target, or struct-literal construction, which itself calls a runtime factory) is a typeck error naming the fix. Emission drops type-only specifiers entirely and drops an import statement whose specifiers are all type-only.

Merge pull request #24 from dekaruntime/fix/next-steps-numbered

scaffold: numbered next steps, green commands, no alternative

scaffold: numbered next steps, commands in green, no alternative form

Next steps: 1. cd myapp 2. npm run dev

Commands are green on a TTY without NO_COLOR; the numbers stay plain. The '# or: npx deka dev' alternative is gone.

Merge pull request #23 from dekaruntime/fix/next-steps-project-scoped

scaffold: project-scoped next steps, single banner

scaffold: project-scoped next steps, single banner

deka is never on PATH after npm create deka-app: it installs @dekaruntime/deka as a project devDependency, so only node_modules/.bin/deka exists. deka init's own "Next steps" doesn't know that and always suggests a bare deka dev, which fails with command not found.

create-deka-app now prints its own "Next steps", scoped to the detected package manager (npm/pnpm/yarn/bun), always via that manager's own dev script with the direct node_modules/.bin form as an alternative. deka init's own banner and "Next steps" block are suppressed via a streaming line filter (src/init-output-filter.js) piped from deka init's stderr (verified against the real binary: that's where it prints everything, not stdout) in real time, so the per-file [create] lines still appear as the scaffold happens instead of being buffered and dumped at the end. create-deka-app prints its own copy of the deka banner (copied byte-for-byte from the real binary, src/banner.js) once, up front, before the install step, whose log line is now "Installing the deka runtime with ...".

Merge pull request #22 from dekaruntime/rfd68/canary-channel

Add canary/stable release channels (rfd#68)

Add canary/stable release channels (rfd#68)

Every deka/dsc build is now a canary (X.Y.Z-canary-); a stable release (plain X.Y.Z) is the same bytes promoted later. Teaches publish-runtime.yml, scripts/sync.js and scripts/lib/manifest.js to resolve, verify and publish either channel, and create-deka-app to stay in lockstep within a channel (a canary create-deka-app pins the matching canary deka, and falls back to the canary dist-tag, not latest).

• publish-runtime.yml: CHANNEL is derived from VERSION wherever VERSION is already known; the schedule leg now checks both channels per family (latest.json/canary.json, latest/release.json/canary/release.json), skipping quietly when a canary pointer 404s. Idempotency, publishing (--tag canary) and "Verify latest" are all channel-aware (dist-tags.canary vs dist-tags.latest). repository_dispatch now reads {tag, channel}, deriving VERSION from tag (old version key still works). workflow_dispatch's version input accepts either channel and a leading "v" or not.
• scripts/lib/manifest.js: per-version R2 path shape is unchanged (deka never had a "v" prefix, dsc always did) -- only the new canary.json / canary/release.json pointers are added.
• scripts/sync.js: smoke-tests a binary against its manifest's base_version (falling back to stripping "-canary-" from the version), since a canary's binary reports the base version on --version, never the canary suffix -- promotion republishes the identical bytes.
• src/channel.js: shared channel/base-version helpers, used by both scaffold.js (shipped) and scripts/lib/manifest.js (not shipped).
• README: Channels section.

Merge pull request #21 from dekaruntime/fix/preflight-before-publish

publish: pre-flight every package before the first publish