Developers on macOS committed a dependency lock file after a provider upgrade. Linux CI runners now fail during terraform init, reporting that the provider package checksum doesn't match any checksum recorded in the lock file. What fixes this properly?

The dependency lock file records the selected version of each provider and the package checksums Terraform trusts for it. When a lock file was produced on one platform and the registry cannot provide signed checksums covering every platform, it may contain hashes that only match that platform's package, so a runner on another platform finds a package whose checksum is not recorded and refuses it. The terraform providers lock command analyzes the configuration's providers, fetches their data from the origin registry and updates the lock file; each -platform option, given as an operating system and architecture such as linux_amd64 or darwin_arm64, makes it save enough checksums to support that platform. Running it once for all platforms in use and committing the result fixes CI without weakening verification. Deleting the lock file in CI discards version pinning and checksum verification, so each run could select a different version and nothing ties CI to what developers tested. The -upgrade option on init ignores existing selections and may choose a newer version within the constraints, which changes behavior rather than just adding checksums. An exact version constraint controls which version is selected but does not disable checksum verification. Exam caveat: the lock file covers providers only, not modules. Operational check: rerun init on a Linux runner with the updated file and confirm it completes without lock file changes.