docs(construct): align golang and zig guidelines concurrency posture with §3.2 v1.31

Add serial-fallback/trade-off clause to Core Philosophy of
spacecraft-golang-guidelines and spacecraft-zig-guidelines: adopt
concurrency where it advances performance; keep serial where the workload
is inherently serial or small, or where concurrency would add overhead /
contention or compromise Stability (Priority 1) — and document the
trade-off. Mirrors the workload-driven framing synced to
spacecraft-rust-guidelines in f1fed47.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: UnbreakableMJ

spacecraft-golang-guidelines.skill

@@ -14,6 +14,7 @@ description: Use for writing memory-safe very high-quality high-speed high-perfo
 ## Core Philosophy
 - Go's goroutines + channels + race detector deliver memory safety and fearless concurrency — the compiler and runtime prevent most data races and use-after-free.
 - Target near-linear scaling across CPU cores for CPU-bound workloads with minimal GC pressure.
+- **Match concurrency to the workload (Standard §3.2):** adopt it where it advances performance (data-parallel, CPU-bound, high-throughput I/O); where the workload is inherently serial or small, or concurrency would add synchronization overhead/contention or compromise Stability (Priority 1), keep it serial and **document the trade-off**. Benchmark to decide.
 - Prefer structured concurrency (errgroup, context, worker pools) over raw `go` statements.
 - Zero-overhead where possible: value types, sync.Pool, escape analysis, contiguous memory.
 - Measure everything: benchmarks, pprof (CPU/heap/goroutine/mutex), go tool trace, and `-race` before claiming "fast".

spacecraft-golang-guidelines.zip

@@ -15,6 +15,7 @@ description: Use for writing memory-safe very high-quality high-speed high-perfo
 
 - Zig's explicitness enables memory safety without GC or borrow checker — leverage comptime, safety modes, allocators, and disciplined ownership.
 - Target near-linear scaling across all CPU cores for CPU-bound workloads.
+- **Match concurrency to the workload (Standard §3.2):** adopt it where it advances performance (data-parallel, CPU-bound, high-throughput I/O); where the workload is inherently serial or small, or concurrency would add synchronization overhead/contention or compromise Stability (Priority 1), keep it serial and **document the trade-off**. Benchmark to decide.
 - Prefer zero-overhead abstractions, manual memory control, lock-free atomics, and data-parallel designs.
 - Use ReleaseSafe/Debug during development and verification; switch to ReleaseFast only after proving correctness and measuring.
 - Measure scaling efficiency, cache behavior, and contention before and after every change.