chore(nix): dedupe logos-nix with follows

[gmelodie]

Summary

logos-module-builder is the aggregator every module depends on. It pulls a stack of logos-* inputs directly, and each one vendored its own copy of logos-nix. This PR pins them all to the root logos-nix with follows, so the builder and every downstream module lock share one copy instead of N.

Before this PR, only logos-test-framework.inputs.logos-cpp-sdk was deduped. This adds inputs.logos-nix.follows = "logos-nix" to every top-level input that carried a private logos-nix:

• logos-cpp-sdk
• logos-protocol
• logos-qt-sdk
• logos-module
• logos-plugin-qt
• logos-plugin-core
• logos-design-system
• logos-view-module-runtime
• logos-standalone-app
• logos-test-framework
• nix-bundle-lgx
• nix-bundle-logos-module-install

logos-view-module and logos-rust-sdk already carried the follows on master, so the whole top-level set is now covered.

Result

Measured on the rebased branch against master 3711449. A logos-nix copy is a lock node whose locked repo is logos-nix.

metric	master	this PR
nodes	360	324
logos-nix node copies	77	65

No input revision moves. Every input resolves to the same logos-nix rev as before, shared instead of duplicated. nix flake metadata evaluates.

Scope

Top-level input edges only. The 65 logos-nix copies that remain are transitive: logos-module pulls 15, nix-bundle-dir 10, logos-package 7, and the rest are spread over logos-package-manager, nix-bundle-appimage, logos-container, logos-module-loader and the SDK repos. Each of those must add the follows in its own flake, so they are out of scope here.

[github-actions]

📊 Doc-test reports

The four ways to wrap a C library plus the two cross-language composition tours — each scaffolded into real modules, built against this commit, loaded in logoscore, and driven — rendered alongside the commands actually run and their output (updated each run, commit c7e4aa8):

• ubuntu-latest report
• macos-latest report

Pages can take a minute to update after the run finishes.

[danisharora099]

This is the companion logos-co/logos-nix#5 needs, and it is green, but I think it is two inputs short of complete.

#5 names these as each carrying their own logos-nix edge: logos-cpp-sdk, logos-qt-sdk, logos-module, logos-protocol, logos-plugin-qt/core, logos-design-system, logos-standalone-app, logos-test-framework, logos-view-module-runtime, and both nix-bundle-*.

This PR adds follows for all of those except logos-design-system and logos-view-module-runtime. Both appear in flake.nix but neither gets inputs.logos-nix.follows.

If #5's list is right, those two stay on the old nixpkgs after both PRs land, which is the split graph #5's own matrix shows failing with uses incompatible Qt library. If they do not actually expose a logos-nix input, or get it transitively through something already followed, then it is #5's list that needs correcting.

Either way worth resolving before these two merge, since they have to land in lockstep. Everything else here looks right, and deduping to one logos-nix is clearly the correct shape.

Caveat: I read the diff rather than evaluating the flake, so the transitive case is exactly what I cannot rule out from here.

[gmelodie]

@danisharora099 the pr was just old-ish (I think when it was created those two deps didn't exist. Added now.

[danisharora099]

Resolved on my side, and thanks for the quick turnaround.

I re-checked by evaluation rather than by reading the diff this time, and both edges are
present at the current head: logos-design-system at flake.nix:105 and
logos-view-module-runtime at flake.nix:115. All fourteen top-level inputs carrying a
logos-nix edge resolve to the root's logos-nix. Neither of those two gets it
transitively, so they did genuinely need the explicit follows, and logos-co/logos-nix#5's
list was right.

I also ran the experiment that matters for the pair: pinning the root logos-nix to #5's
head and instantiating the same check on both trees. The split-graph failure #5 warns about
reproduces without this PR, and this PR closes it. So the two really do need to land
together.

One thing left in the way, unrelated to the above: this branch is currently CONFLICTING
and 13 commits behind master, and its lock reverts nine root inputs to their 2026-08-20
revisions. It needs a rebase and relock before it can merge in lockstep with #5.

[gmelodie]

Rebased!