docs(construct): sync downstream skills to Steelbore Standard §3.2 (v1.30/v1.31)

Propagate the two §3.2 content changes into the downstream skills that restate or
instruct on §3.2 rules:

- v1.30 (concurrency reframe): concurrency is an architecture-level concern
  considered from the ground up; adopt where it advances performance, abandon
  where it degrades it or compromises Stability, and document the trade-off.
- v1.31 (compiler-flags notation): BOTH applied and disabled optimization flags
  must be explicitly noted (build file or build-time message), and any flag that
  breaks/destabilizes a build MUST be disabled (Stability > Performance).

microsoft-rust-guidelines §3.2: full update (concurrency + applied/disabled flag
documentation symmetry + §3.2.1 cross-ref). golang & zig: their release-build-flag
bullets now carry the applied/disabled documentation rule.

No change to spacecraft-rust-guidelines (already "design concurrency in from the
start; match aggression to workload"), elixir/erlang ("concurrency is the default
lever" — aligned), or gnu-coding-standards (already cites §3.2.1; GNU CFLAGS
philosophy left intact). Bundles rebuilt; drift sweep clean; reuse lint 326/326.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: UnbreakableMJ

microsoft-rust-guidelines.skill

@@ -182,11 +182,21 @@ are not manifests) are exempt; software source files are not.
 
 ### §3.2 — Performance
 
-- Concurrency must be **designed-in from the start**, never bolted on retroactively.
-- Release profiles must use `-C target-cpu=native` (or `RUSTFLAGS=-C target-cpu=native`),
-  LTO (`lto = true`), and PGO where the toolchain supports it.
-- Benchmarking is **mandatory** before and after any optimization work; regressions
-  must be documented and justified.
+- Concurrency is an **architecture-level concern** — designed in from the start, never
+  bolted on. Adopt it where it genuinely advances performance; where it would degrade
+  performance (synchronization overhead, lock contention, inherently serial or small
+  workloads) or compromise Stability (Priority 1), choose the simpler serial approach and
+  **document the trade-off**.
+- Release profiles should use `-C target-cpu=native` (or `RUSTFLAGS=-C target-cpu=native`),
+  LTO (`lto = true`), and PGO where the toolchain supports them reliably. **Note every
+  applied flag and every disabled flag (with its reason)** — a comment in `Cargo.toml` /
+  `build.rs` or a build-time message — so flag state is visible at compile time. Any flag
+  that breaks or destabilizes the build on a given platform/toolchain (e.g. LTO under some
+  NixOS, cross-compilation, or static-linking setups) MUST be disabled; Stability
+  (Priority 1) outranks Performance. See `spacecraft-standard` §3.2.1.
+- Benchmarking is **mandatory** before and after any optimization work; regressions must
+  be documented and justified — it is also the evidence for the concurrency-vs-serial
+  trade-off above.
 
 ### §3.3 — Security & Dependency Auditing
 

microsoft-rust-guidelines.zip

@@ -64,7 +64,9 @@ Never use raw `go func() { ... }()` without a `sync.WaitGroup` or `errgroup` in
 
 ## Build, Tooling & CI (Non-Negotiable)
 - `go test -race ./...` must pass (enforce in CI).
-- Release builds: `go build -ldflags="-s -w"`.
+- Release builds: `go build -ldflags="-s -w"`. Per `spacecraft-standard` §3.2, note every
+  applied optimization/linker flag and every disabled one (with the reason) — in the build
+  script or a build-time message — so flag state is visible at compile time.
   > **OS-specific note:** Go's toolchain manages its own linker, but when building
   > cgo-enabled packages that invoke the system C linker on NixOS, LTO and similar
   > cross-module optimizations may require `-fuse-ld=mold` (preferred) or `-fuse-ld=bfd`

microsoft-rust-guidelines/SKILL.md

@@ -81,6 +81,8 @@ Never fall back to raw `std.Thread.spawn` in hot paths — always go through a p
 - Safe development: `zig build -Doptimize=ReleaseSafe` (or Debug).
 - Production verification: same + `std.testing.allocator` runs that must pass with zero leaks.
 - Final performance: `zig build -Doptimize=ReleaseFast` (Zig enables LTO-like behavior via its pipeline).
+  Per `spacecraft-standard` §3.2, note every applied optimization flag and every disabled one
+  (with the reason) — in `build.zig` or a build-time message — so flag state is visible at compile time.
   > **OS-specific note:** When wrapping C libraries or using an external linker on NixOS,
   > LTO may require `-fuse-ld=mold` (preferred) or `-fuse-ld=bfd` because `/nix/store`
   > isolation keeps the GCC LTO plugin off the default linker path. See `spacecraft-standard`