Remove final bootstrap compiler binary after build for supply-chain hardening in Azure Linux Golang packages

[nikhilgv]

Is your feature request related to a problem? Please describe.
Yes. The final bootstrap compiler binary currently remains on the build host or in CI artifacts after the build completes. While not a practical remote exploit vector, keeping a prebuilt compiler increases supply-chain risk and potential exposure — especially if someone rebuilds the SRPM locally.

Describe the solution you'd like
Remove the final bootstrap compiler binary immediately after the ./make.bash --no-clean step and before packaging, ensuring it isn’t persisted in CI caches or build artifacts.

Describe alternatives you've considered

1. Restricting access to the bootstrap on the build host.
2. Adding signing/attestation for the bootstrap binary.
   Both are heavier approaches; simple removal is the most effective and low-impact.

Additional context
This is a proactive security and supply-chain hardening measure, not a response to an active exploit. The current behavior (bootstrap left on disk/artifacts) is observed for these Azure Linux package variants / branches:

• 3.0 golang-1.23
• 3.0 golang-1.24
• 3.0 golang
• 2.0 golang-1.18
• 2.0 golang
• 2.0 msft-golang

Removing the final bootstrapper from these build flows (and any CI caches) will reduce residual attack surface for downstream rebuilds or exposed CI artifacts.

[Googulator]

How exactly is this a security risk?