Rediscover Go settings only when Go work needs them

docs/internal/overview.md

@@ -64,7 +64,9 @@ Candidate checking captures and validates one clean committed source revision
 in `internal/candidate`. Its validation bridge calls `internal/validation` for
 the selected module's default offline Go suite, then runs product-specific
 checks once. Validation and its post-validation build callback share one local
-Go settings owner; the candidate package owns those builds and local-state
+Go settings owner. Each Go acquisition checks inherited and persistent inputs;
+settings are rediscovered when subsequent Go work needs them. An unavailable
+persistent-settings snapshot disables reuse. The candidate package owns builds and local-state
 rechecks; publication owns endpoint guards, tag creation, push, and recovery
 around that same candidate validation path. `internal/validation.CandidateTree` reads
 committed blobs lazily and resolves local destinations from committed entries;

docs/roadmap/remediation.md

@@ -157,7 +157,15 @@ a genuinely different repository or module must still fail before hosted work.
 
 ## Issue 5: Keep Go environment reuse lazy and proportionate (P2)
 
-Status: open. Category: additional validation gates and unrequested restrictions.
+Status: complete. Category: additional validation gates and unrequested restrictions.
+
+**Completion:** Go discovery happens on acquisition for actual Go work. Completed
+callbacks trigger no additional discovery; settings-file snapshot failures disable
+reuse while preserving the Go tool's accepted configurations. Regression tests
+cover check/publication completion after Go leaves PATH, subsequent builds needing
+rediscovery, the final callback, unreadable GOENV snapshots, normal environment
+and persistent-file changes, and cancellation. Focused public cases and complete
+candidate and Go-tool suites pass offline.
 
 **Evidence:** [candidate coordination](../../internal/candidate/check.go) and
 [publication](../../internal/publish/publish.go) eagerly call