build(native): read bridge toolchains from their pin files

[datlechin]

Why

build-hana.sh forced go1.27.1 over the toolchain go1.27.2 pin in go.mod, so plugin-hana 1.0.1 to 1.0.3 shipped a helper without the GO-2026-6607 fix. build-dameng.sh and CONTRIBUTING.md kept their own copies of the Rust and Go versions. Release rewrite plan, cleanup after step 23; audit item docs-7.

Change

• build-hana.sh sets GOTOOLCHAIN from the toolchain line of go.mod and signs the helper with -o runtime -s -.
• build-dameng.sh runs rustup toolchain install --no-self-update and cargo in the bridge folder, so rust-toolchain.toml picks the release and targets and rustup itself is left alone. both lipos straight from cargo's output into libdameng_bridge.a.
• The universal alias is gone from both scripts.
• One minos check, verify_deployment_target in deployment-target.sh, moved from macos.sh. It reads every slice (otool -arch all) and fails a file that records no minimum.
• CONTRIBUTING.md, the Dameng README and the HANA notices point at the pin files.
• Security fragment for the HANA helper's Go runtime.

Verified

• build-hana.sh both and build-dameng.sh both: lipo shows x86_64 and arm64, minos 13.0, the helper is go1.27.2 with adhoc,runtime and runs on both architectures.
• rustup toolchain install --no-self-update exits 0 with the update server unreachable; without the flag it exits 1.
• The check passes every archive in Libs/ and fails a fat file whose x86_64 slice targets 15.0.
• AllPlugins builds on those outputs and verify-plugin-loads.sh loads all 41, HanaDriver and DamengDriver included.