chore: pin the optionality-parity landing

[dlipicar]

Completes ?T optionality. It was already implemented in logos-lidl, the C++ generators and the Rust provider/consumer; this lands the last two surfaces — the Qt generators, and Option<T> in the Rust-first authoring direction.

input	from	to	brings
logos-qt-sdk	af767b7	3cd5297	#29 optional params on every Qt surface · #30 goldens are valid C++ · #31 jsonReturn shapes are already Qt types
logos-rust-sdk	be0deda	0b4b8ed	#35 Option<T> in the Rust-first frontend · #36 admit ?any + scope the optional-return refusal · #37 refresh roundtrip goldens · #38 typed event emitters speak records
logos-module-builder	5a400e3	ddddd8c	#187 / #188 re-pin the two SDKs
logos-test-modules	fb773a5	f8077fa	#43 typed record emitter call site + SDK triple sourced from module-builder

Optional returns stay refused on the Qt path only

An empty ?T is JSON null, and null is already how a failed call is reported there (logos_json_convert → invalid QVariant → METHOD_FAILED), so "found nothing" would be indistinguishable from "the call failed".

They remain supported on the cdylib path — cpp-sdk keeps them eligible by design, and test_fullapi_ext_{rust,cpp} plus the logoscore-py client exercise echoOptional(v: ?tstr) -> ?tstr as a cross-language conformance case.

Four pre-existing bugs fixed along the way

• unchecked QList::at in the Qt provider dispatch — a caller sending too few arguments read past the end. Now args.value() plus an explicit arity gate.
• int/uint returns cast through static_cast<int> — they are int64_t/uint64_t, so every value past 2³¹ was silently truncated.
• jsonReturn shapes double-converted — any was forced through .toList(), coercing an object or scalar into a list.
• logos-test-modules sourced its SDK triple from logos-liblogos.inputs while compiling code the builder's generator emitted. The two pins drifted independently, and the unit tests stopped compiling the moment cpp-sdk#132 taught the generator to emit #include "logos_async_result.h".

Both halves bumped

flake.lock and the submodule gitlinks. The doctest job pins each submodule to its gitlink via --release-for, so a lock-only bump would leave the doctest side testing the old code.

Lock revs verified at the root level (nodes[root].inputs), not by node name — flake.lock keys are deduplicated, so a node called logos-qt-sdk is not necessarily the one the root resolves.

Verification

Every component PR is merged and green. Raised for the full Tests and Doc-tests run, which is workflow_dispatch-only and does not trigger on PR open — it needs to be launched against this branch.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the workspace’s pinned dependency revisions to land the remaining ?T optionality parity surfaces by bumping the relevant SDK and test-module inputs in the root flake, ensuring the workspace evaluates against the intended upstream commits.

Changes:

• Bump logos-qt-sdk, logos-rust-sdk, logos-module-builder, and logos-test-modules input URLs in flake.nix.
• Refresh flake.lock to reflect the new locked revisions (and updated transitive locks such as logos-lidl where applicable).

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.

File	Description
flake.nix	Updates the flake input URLs to the new upstream commits for qt-sdk, rust-sdk, module-builder, and test-modules.
flake.lock	Updates locked revisions/hashes to match the new workspace pins and their transitive dependency graph.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.