Build and attach the module cdylib to each release

[senamakel]

Summary

Builds tinychannels-module for every supported platform and attaches the
artifacts to each release. Follow-up to #15, where this was raised as a P1 and
deliberately deferred so it would not ride along with the workspace split that
had to touch the same workflow.

Without it the module crate is undeliverable: publish = false means it never
reaches crates.io, and what a host actually loads is the compiled cdylib.
OpenHuman's modules::registry pins each artifact by a SHA-256 digest taken
verbatim from a published release, so until a release carries these archives
the module cannot be pinned and therefore cannot be loaded at all.

Two new jobs, modelled on the equivalent pair in tinyhumansai/tinydocs:

• native-bundles — 11-way matrix, builds --release --package tinychannels-module, packages the library with LICENSE, README.md and a
  modules.toml carrying the library's own digest, uploads one archive per
  platform.
• github-release — collects them, generates checksum.toml with the
  TinyBus CLI, creates the release, then downloads and loads the published
  artifact the way a host would as a final check.

Problem

release.yml published the two Rust crates and stopped. tinychannels-module
was explicitly excluded from packaging (correctly — it is publish = false),
but nothing took its place, so no release has ever carried a loadable module.

Solution

The matrix is per-distro, not per-target, and that is the point. A .so
built against glibc 2.39 fails to dlopen on a 2.35 host with a symbol-version
error the ABI gate cannot phrase helpfully. OpenHuman's modules::platform
probes glibc and prefers the newest build that could work — which only helps if
the older build exists. Hence ubuntu-22.04 and ubuntu-24.04, each in both
architectures, plus two macOS generations and three Windows runners.

Decisions worth reviewing:

• fail-fast: false, plus a hard asset-count check. One unavailable runner
  should not cost the other ten artifacts, but a partial set must never be
  published — a release missing ubuntu-22.04-arm64 is one that silently cannot
  be installed on that platform. So the matrix tolerates a failure and
  github-release refuses anything other than exactly 11 archives.
• Jobs check out the tag, not main. ref: needs.publish-rust.outputs.tag,
  so the artifact matches the released source rather than whatever main moved
  on to while the matrix was running. This required adding an outputs: block to
  publish-rust, which previously exposed nothing.
• The native target is asserted before building. The whole per-distro scheme
  rests on each id describing the machine that built it; a runner image that
  changed architecture would otherwise produce a correctly-named artifact that
  cannot load.
• checksum.toml is generated by the TinyBus CLI, not by hand. It is the
  manifest the loader compares its pinned digest against, so the writer and the
  reader stay the same implementation. There are two digests by design: the
  in-archive modules.toml covers the library, the release-level
  checksum.toml covers the archives, and the host checks both.
• The release is verified by loading it. The last step fetches the published
  ubuntu-24.04-x86_64 archive through tinybus's github_module_host example
  using the digest from the manifest — so a release that cannot actually be
  installed fails here rather than in the field on whichever platform nobody
  tested.

Verification

A release workflow cannot be exercised without cutting a tag, so I verified the
parts that are testable locally rather than claiming more than I checked:

• cargo build --locked --release --package tinychannels-module succeeds, and
  emits target/release/libtinychannels_module.so — the exact path and library
  name the packaging step derives.
• The Unix packaging block was run as written against that build: it produces
  tinychannels-module-<version>-<id>.tar.gz containing the library, LICENSE,
  README.md and a well-formed modules.toml.
• The tinybus modules checksum subcommand and the github_module_host example
  both exist in the vendored vendor/tinybus (c35105f) at the paths the
  workflow invokes.
• The workflow parses as YAML and resolves to three jobs with an 11-entry matrix.

Not verified, and cannot be until a real release runs: the runner labels
themselves (ubuntu-22.04-arm, macos-26-intel, windows-11-arm), the Windows
PowerShell packaging block, and the cross-job artifact hand-off. These are taken
from tinydocs' workflow, which exercises them on every release.

Impact

• Release-time only; no library or module code changes.
• The crate publish path is untouched — the new jobs needs: publish-rust and
  run after it, so a failure in either cannot affect what reaches crates.io.
• First release after this merges is the one that unblocks pinning
  tinychannels in OpenHuman's modules::registry.

Related

• Follows up Split TinyChannels into contract, implementation and module crates #15 (thread on .github/workflows/release.yml:141).
• Unblocks: pinning the module in tinyhumansai/openhuman, then moving the
  channels runtime onto the bus.

[coderabbitai]

Important

Approval pending

CodeRabbit has no unresolved comments, but it has not reviewed the latest commit.

Use the checkbox below to review the latest commit. CodeRabbit will approve the changes if it finds no blocking issues.

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-30T12:12:57.600034Z	890b98e	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[tinysweeper]

tinysweeper found nothing blocking. Approving.

             $0.0068 · 76,823 in / 1,917 out · 8,826 cached (11%) · openrouter/openai/text-embedding-3-small, deepseek/deepseek-v4-flash, z-ai/glm-5.2 · 407 embedded
critique:    $0.0025 · 29,910 in / 1,011 out · 0 cached (0%)      · deepseek/deepseek-v4-flash
security:    $0.0025 · 25,198 in / 732 out   · 8,826 cached (35%) · z-ai/glm-5.2, deepseek/deepseek-v4-flash
tests:       $0.0012 · 14,421 in / 106 out   · 0 cached (0%)      · deepseek/deepseek-v4-flash
description: $0.0006 · 7,294 in  / 68 out    · 0 cached (0%)      · deepseek/deepseek-v4-flash

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 890b98ee1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[senamakel]

PR babysitter status

Head: c3912ef

Fixes pushed this pass:

• c3912ef — packaging step now falls back to shasum -a 256 when sha256sum (GNU coreutils) isn't on PATH, fixing the macOS matrix legs Codex flagged (P1).

Feedback handled:

• Codex (.github/workflows/release.yml:312, macOS-incompatible sha256sum): CONFIRMED, fixed in c3912ef, thread resolved.
• tinysweeper (3 threads, unpinned dtolnay/rust-toolchain@stable / Swatinem/rust-cache@v2): NOT_ACTIONABLE for this PR — these lines copy the pre-existing repo convention already present unpinned at release.yml:42/46 and ci.yml:31/35. Repo-wide SHA-pinning is a legitimate follow-up but out of scope here; partial pinning would leave the file inconsistent without closing the gap. Replied with evidence on all three threads, resolved.
• tinysweeper APPROVED review (pre-push).

CI: Rust SDK ✅ ✅, CodeRabbit ✅ (rate-limited, non-blocking pass). tinysweeper/review reports action_required with output stating "No code was reviewed... it is not a finding about this pull request" — a schema-validation failure inside tinysweeper's own model call (missing field 'severity'), not something this PR's code can fix. No branch protection / required checks are configured on this repo. Re-run attempted via the Checks API (rerequest) and rejected (404) — not retriggerable from here.

Threads: 4 resolved, 0 actionable remaining. Blocking reviews: 0.

Proceeding to merge per explicit authorization, given all real CI is green, all feedback is addressed, and the failing check is an external bot-infra issue whose own output says to merge by hand once reviewed.