fix(build): skip asm scan for synthetic test main

[visualfc]

Summary

Fix llgo test for packages whose source directories contain assembly files.

The synthetic test main package shares the tested package's directory, causing LLGo's assembly scan to find unrelated
.s files and run go list with a generated package path such as github.com/visualfc/gid.test. That path is not
directly loadable, so the build failed.

Skip assembly discovery for synthetic test main packages and cache the empty result.

Testing

• go test ./internal/build -count=1
• Built LLGo from this branch and ran llgo test -v in github.com/visualfc/gid
• git diff --check

[fennoai]

Review summary

This is a tight, well-scoped fix. pkgSFiles now short-circuits the synthetic test-main package (*.test) before the directory .s glob and the go list subprocess, which correctly avoids both false-positive assembly detection (the testmain shares the tested package's dir) and a guaranteed-to-fail go list on a non-listable generated import path. The added comment accurately explains the rationale, the guard caches nil consistently with the sibling early returns, and a focused test covers the happy path plus the cache entry.

Security: clean — subprocess uses exec.Command (no shell), inputs come from the toolchain's package graph, and only GOOS/GOARCH are added to the env.
Performance: a net win — the guard removes a filesystem glob and an external process on the test path.

Two non-blocking suggestions below (maintainability + test robustness). No blocking issues.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

LLGo baseline benchmarks

2212bba3885a | workflow run | long-term charts

Program measurements

Platform	Workload	File size	vs base	Build	vs base	Run	vs base
Linux	cprintf	19248 B	+0.0%	343.888 ms	+2.2% (worse)	1.388 ms	-2.2% (better)
Linux	fmtprintf	1879904 B	+0.0%	2.718 s	+0.3% (worse)	3.227 ms	-6.5% (better)
Linux	println	68616 B	+0.0%	342.724 ms	+2.4% (worse)	1.711 ms	-2.6% (better)
macOS	cprintf	84624 B	+0.0%	340.854 ms	+5.0% (worse)	2.566 ms	+8.9% (worse)
macOS	fmtprintf	1891424 B	+0.0%	2.972 s	+36.6% (worse)	15.845 ms	+30.6% (worse)
macOS	println	121168 B	+0.0%	331.656 ms	+2.3% (worse)	3.798 ms	-10.7% (better)

Core language and compiler benchmarks

Platform	Benchmark	ns/op	vs base
Linux	BenchmarkLookupPCRandom	13.390 ns/op	+0.5% (worse)
Linux	BenchmarkMergeCompilerFlags	150.800 ns/op	+0.3% (worse)
Linux	BenchmarkMergeLinkerFlags	94.870 ns/op	+0.7% (worse)
Linux	BenchmarkChannelBuffered	35.200 ns/op	+0.0% (worse)
Linux	BenchmarkChannelHandoff	26978 ns/op	+1.1% (worse)
Linux	BenchmarkDefer	47.220 ns/op	+1.6% (worse)
Linux	BenchmarkDirectCall	1.556 ns/op	-0.1% (better)
Linux	BenchmarkGlobalRead	1.564 ns/op	+0.5% (worse)
Linux	BenchmarkGlobalWrite	2.488 ns/op	+0.0% (worse)
Linux	BenchmarkGoroutine	32443 ns/op	-0.1% (better)
Linux	BenchmarkInterfaceCall	7.788 ns/op	+0.0% (worse)
Linux	BenchmarkRuntimeGetG	2.499 ns/op	+0.2% (worse)
macOS	BenchmarkLookupPCRandom	14.510 ns/op	+31.0% (worse)
macOS	BenchmarkMergeCompilerFlags	120.100 ns/op	+12.1% (worse)
macOS	BenchmarkMergeLinkerFlags	87.070 ns/op	+16.5% (worse)
macOS	BenchmarkChannelBuffered	32.590 ns/op	+52.8% (worse)
macOS	BenchmarkChannelHandoff	9483 ns/op	+5.2% (worse)
macOS	BenchmarkDefer	43.570 ns/op	+59.5% (worse)
macOS	BenchmarkDirectCall	1.281 ns/op	+20.5% (worse)
macOS	BenchmarkGlobalRead	1.451 ns/op	+46.4% (worse)
macOS	BenchmarkGlobalWrite	1.832 ns/op	+84.8% (worse)
macOS	BenchmarkGoroutine	49022 ns/op	+77.0% (worse)
macOS	BenchmarkInterfaceCall	7.335 ns/op	+29.1% (worse)
macOS	BenchmarkRuntimeGetG	2.373 ns/op	+7.7% (worse)

Compared with 7d9f052513f2 measured in the same runner job.