fix: preserve package link flags on shared-library link units #771

Reproduction

mcpp 2026.10.5.1 on Windows, using LLVM 22.1.8 and the MSVC ABI.

A workspace member has a shared-library target and declares its link dependencies in build.mcpp:

[package]
name = "player"
version = "0.1.0"

[build]
sources = ["player.cpp"]

[targets.player_dll]
kind = "shared"
windows_auto_export = false

// build.mcpp
import mcpp;
int main() {
    mcpp::link_lib("d3d11");
    mcpp::link_lib("dcomp");
    mcpp::link_lib("delayimp");
    mcpp::link_flag("-Wl,/DELAYLOAD:dcomp.dll");
}

The shared-library source calls D3D11CreateDevice and DCompositionCreateDevice. Build the workspace, or select the member with mcpp build -p player.

Actual behavior

The build-program cache contains -ld3d11, -ldcomp, -ldelayimp and -Wl,/DELAYLOAD:dcomp.dll. The DLL link command contains only the plan's base flags, omitting those declarations. LLD reports undefined D3D11CreateDevice and DCompositionCreateDevice symbols. A sibling executable receives the member's flags.

The problem became visible after removing source-level #pragma comment(lib, ...) directives, which had independently carried the missing library declarations into the object files.

Expected behavior

Each shared library uses the link configuration of its owning package and the dependencies linked into that image. Selecting another workspace member must not remove those flags or replace them with unrelated members' flags.

Source trace

At c94234b (2026.10.5.1), src/build/plan.cppm creates dependency-owned shared link units in the sharedDepTargets loop without assigning a linkGroup. Later, workspace-member planning creates each member's group but skips its shared targets because they were already created. src/build/ninja_backend.cppm consequently emits these DLL links with the plan-global flags instead of their owners' link usage.

This also needs coverage for shared libraries reached through ordinary path dependencies, not only explicitly selected workspace members.