[FEATURE] Add Go language support — assessors skip or mis-measure on Go-majority repos

[Dharit13]

Problem Statement

Several assessors that should apply to Go projects either skip with "Not applicable" or fail because their measurement logic is Python/JS-specific. Running v2.31.2 against a Go-majority repo (89 Go / 9 Python files) produces false negatives across five attributes and falsely skips two more, materially understating the score.

This was hinted at in #329 (which planned assessors/langs/go.py) but the language-modular work doesn't appear to have shipped yet for Go.

Proposed Solution

Implement assessors/langs/go.py per the structure described in #329, covering:

Attribute	Today on Go repos	What Go offers
test_coverage	Skipped: "Not applicable to YAML/Markdown/Go/JSON/Shell/Python"	go test -cover produces standard coverage.out profiles. Detect via go.mod + *_test.go.
structured_logging	Skipped: "No Python dependency files found"	Detect log/slog (stdlib, Go 1.21+), zap, zerolog, logrus via go.sum import scan.
type_annotations	Fails (24.6% — measures Python type hints)	Go is statically typed by construction. For typed languages, this attribute should pass-by-default or be N/A.
inline_documentation	Fails (12.3% — measures Python docstrings / JSDoc)	Go's // doc-comment convention on exported identifiers, enforceable via revive / staticcheck.
standard_layout	Fails (0/2 — looks for src/ + tests/)	Go's standard layout is cmd/ + internal/ + pkg/ (reference). Detection signal: go.mod present.

Alternatives Considered

1. Per-language config overrides — Have users disable irrelevant assessors with --exclude. Doesn't help leaderboard comparability and pushes the work onto every Go-repo submitter.
2. Mark all five as N/A on Go — Removes the false negative but undercounts coverage; better to measure the Go-equivalent.
3. Defer to existing Go tooling — gocoverage, staticcheck for docs, etc. as subprocesses. Heavier dependency surface; the detections above are mostly grep-level.

Use Cases

1. Submitting a Go-majority repo to the leaderboard without first hand-arguing the score (concrete example: fullsend-ai/fullsend submission for fullsend-ai/fullsend#538).
2. Cross-language fairness on the leaderboard — Python repos shouldn't have a structural advantage from happening to match the assessor's default measurement method.
3. Calibrating the ruleset per the invitation in [BUG] why is agentready only scoring ~80 #121.

Additional Context

Reproduction (against fullsend-ai/fullsend@cba01190):

git clone https://github.com/fullsend-ai/fullsend /tmp/fullsend
cd /tmp/fullsend && git checkout cba01190
uvx --from git+https://github.com/ambient-code/agentready agentready -- assess .
# Score: 51.3/100 (Bronze), 21/29 assessed

After accounting for the items above, the realistic assessable count is 24/29 and three of those would almost certainly pass.

Acceptance Criteria

• assessors/langs/go.py module exists per [FEATURE] Extract language-specific assessor logic into separate modules #329's structure
• test_coverage recognises Go (go.mod + *_test.go)
• structured_logging recognises log/slog, zap, zerolog, logrus
• type_annotations either passes for Go or marks N/A consistently with other typed-by-construction languages
• inline_documentation recognises Go doc-comments on exported identifiers
• standard_layout recognises cmd/ + internal/ (and/or pkg/) as a valid layout
• Re-running assess on a representative Go repo produces a score that reflects actual readiness

Priority

• Critical (blocking my work)
• High (significantly improves workflow)
• Medium (nice to have)
• Low (minor enhancement)