Fix assembly privacy checks and build provenance inputs

[huitseeker]

This closes #2945, closes #2712, and closes #2897.

Some assembly imports were resolved without checking whether the target item was public, and signature-only type uses were skipped by the import visitor. Build reuse also depended on manifest data that should not affect compiled output.

This PR:

• rejects private cross-module imports, including absolute-path aliases
• counts imports used only in procedure signatures
• narrows build provenance to fields that affect output
• marks required core STARK helper procedures public
• updates generated core library docs for those public procedures

Design decisions that could have gone another way:

1. Build provenance means target-specific build identity: does not mean the full effective manifest hash. Only fields that can affect the selected target’s artifact should trigger rebuild/reuse changes.
2. The project model owns provenance classification: Assembly shouldn't hash rendered TOML or infer meaning from serialization.
3. Unrelated manifest data should not affect artifact reuse: Adding or changing another target should not rebuild a library artifact unless it can affect that library’s package output.
4. Module visibility applies to all item kinds: Private procedures, constants, and types are all private across module boundaries. Constants are not exempt just because they are compile-time values. This is why this PR includes some masm changes.
5. Signature-only type references count as import usage: A type used only in a proc argument or result is still semantically used, so its import must be retained / validated.

[bitwalker]

Design decisions that could have gone another way:

1. Build provenance means target-specific build identity: does not mean the full effective manifest hash. Only fields that can affect the selected target’s artifact should trigger rebuild/reuse changes.
2. The project model owns provenance classification: Assembly shouldn't hash rendered TOML or infer meaning from serialization.
3. Unrelated manifest data should not affect artifact reuse: Adding or changing another target should not rebuild a library artifact unless it can affect that library’s package output.
4. Module visibility applies to all item kinds: Private procedures, constants, and types are all private across module boundaries. Constants are not exempt just because they are compile-time values. This is why this PR includes some masm changes.
5. Signature-only type references count as import usage: A type used only in a proc argument or result is still semantically used, so its import must be retained / validated.

All those seem fine to me.

I think the main thing missing here is that we must reject the use of private type declarations in the signature of exported procedures, since it would cause dangling references in the final package in some cases (namely enum types). The type system is structural, not nominal, so most type aliases are transparent (i.e. a private type alias could appear in an exported signature and it wouldn't have an impact on the type signature encoded in the final package) - but for the purpose of binding generation in Rust/other languages, we will probably move towards preserving at least some names in the final artifact, so rejecting that as an edge case will make that doable without causing breakages at some point.

[huitseeker]

@bitwalker Right on, I opened #3092.

[Al-Kindi-0]

LGTM, modulo a couple of questions

[Al-Kindi-0]

Q: What is the intention of this test ?

[huitseeker]

The test checks that bundle --kernel can still produce a package when the bundled library has no exports. After the new privacy rule, the old fixture was invalid because its kernel called a private proc from lib_noexports. The new kernel_noexports.masm keeps the same test intent without relying on a private cross-module call.