deps: go-asmgen v0.16.0 with regenerated kernels; Go 1.27.1 checked on real loong64

[tannevaled]

Supersedes #28. That PR bumps the module but leaves the committed .s files stale, so the ppc64le and loong64 regeneration checks fail.

Generator

• go-asmgen v0.14.0 → v0.16.0. go mod tidy drops the old sums.
• Regenerated sum_ppc64le.s (164 lines) and sum_loong64.s (20 lines). With the comments stripped, the removed and added lines are identical: v0.15+ only writes the proposed Plan 9 spelling into each WORD's comment. amd64 and arm64 regenerate byte-identical.
• The pin to v0.14.0 was only there while the library was on go 1.26; build: raise the Go floor to 1.27.1 #27 moved it to 1.27.1.

Go 1.27.1 on loong64 (golang/go#81000)

#27 accepted a known risk: go1.27.0 and go1.27.1 miscompile a loong64 pattern, a byte-sized inlined result spilled with an 8-byte store. Checked on a real Loongson 3C5000L (cfarm401, LASX detected), with binaries built by go1.27.1:

• the root, kernels and benchmarks test suites all PASS, including the PROT_NONE fence tests;
• FuzzOps ran natively for 3 minutes, 52.7M executions with no divergence from its oracle.

This is evidence, not proof. SECURITY.md records it and says to raise the floor to 1.27.2 when it is released.

Docs

• The README Go badge said 1.26.6+; go.mod requires 1.27.1. Fixed.
• govulncheck under go1.27.1 reports no vulnerability for the library or for the generator module; logged in SECURITY.md.

Version: v0.5.1.

🤖 Generated with Claude Code