feat(wiring): library composition with cross-package types

[zoe-codez]

Changes

• Adds LibraryGroup({ name?, members, registry? }) to compose libraries as a single membership unit (replaces the unmerged RollupLibraries). registry: "<name>" generates the priorityInit registry-service wiring (the plugin-registry pattern).
• depends now resolves transitive membership automatically (closure-as-membership, identity-deduped); every auto-pulled library is narrated in the boot log.
• implies and depends carry member types across package boundaries with no manual re-export; directly-listed types take priority over hoisted ones.
• DUPLICATE_LIBRARY is a fixed three-case rule with a fact-only message (no remediation prose).
• Adds yarn type-check as a CI gate and a yarn test:cross-package proof for the cross-package type channel.

Companion docs PR: Digital-Alchemy-TS/documentation#68

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.74%. Comparing base (69ca0f6) to head (af453b8).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #333      +/-   ##
==========================================
+ Coverage   97.57%   97.74%   +0.17%     
==========================================
  Files          24       24              
  Lines        1276     1373      +97     
  Branches      251      288      +37     
==========================================
+ Hits         1245     1342      +97     
  Misses         30       30              
  Partials        1        1              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hfesel-rvoh]

Comments with the help of Claude! Otherwise it looks good. The implies with no depends seems like the biggest risk to me

[hfesel-rvoh]

assertLibraryNames now filters rollups out before counting, but it's also called from CreateApplication (assertLibraryNames(libraries), ~line 413) on the un-flattened input. So a RollupLibraries([...]) containing a same-name/different-object collision is no longer caught at definition time — only at bootstrap after flattenLibraries expands it. That contradicts the @throws DUPLICATE_LIBRARY / "fail loudly at definition time" promise in the CreateApplication TSDoc (line 384) and assertLibraryNames's own doc. Either expand rollups in the definition-time check, or update those doc comments to note rollup contents are validated at bootstrap. (Bootstrap does catch it — the rejects same-name/different-object delivered via a rollup test confirms — so this is doc accuracy, not a hole.)

[hfesel-rvoh]

Worth making the ordering hazard explicit here since this is the field's doc: implies contributes membership with no ordering edge, so a consumer that sets only implies: [X] (not depends: [X]) and reads params.X in the factory body — rather than inside a lifecycle hook — can get undefined if X wires after the implier. The README and demo cover it (the demo sets both), but a one-line @remarks pointing readers to pair implies with depends when they touch the member at wire time would prevent the obvious misuse.