fix(orchestrator): stop force-marking publish failures retryable

[sbalabanov]

Summary

The validate, buildsignal, and merge orchestrator controllers wrapped every queue-publish failure with errs.NewRetryableError, retrying unconditionally regardless of the actual cause. That defeats the classifier framework: only known-transient infra errors should retry — otherwise a genuinely non-retryable failure replays forever instead of dead-lettering.

These three sites return the raw error and let the consumer's ErrorProcessor classify it, the same as every other error path.

Changes

• Controllers — validate.go, buildsignal.go, merge.go: return the raw publish error (fmt.Errorf("...: %w", err)) instead of errs.NewRetryableError(...). Dropped the now-unused errs imports in buildsignal/merge (gazelle removed the matching BUILD deps).
• Tests — removed the IsRetryable assertions from the publish-failure tests; classification is the consumer's contract, not the controller's. The tests now assert that an error surfaces. Renamed TestProcess_PublishFailureIsRetryable → TestProcess_PublishFailureReturnsError.
• Docs — CLAUDE.md and platform/errs/README.md: clarify that classifiers own retryability, controllers override only with knowledge a classifier lacks (never just because replaying is convenient), and IsRetryable is meaningful only after the ErrorProcessor pass — i.e. detected in the consumer/transport layer, not in controllers.

Testing

• go test ./submitqueue/orchestrator/controller/{validate,buildsignal,merge}/... ./platform/errs/... — pass
• make gazelle — BUILD files synced
• gofmt — clean

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}