🛠️ Refactor: Centralize error reporting and fix linters

[google-labs-jules]

This PR introduces a centralized ReportError function to handle all unexpected errors across the application, complying with the Single Responsibility Principle. This ensures consistent structured logging and makes it easy to integrate future backends like Sentry without modifying call sites.

Additionally, this PR fixes several linter errors:

• Fixed an infinite loop bug in tcp.go caused by using break inside a select block instead of return nil.
• Optimized bufferPool in tcp.go to return a pointer (*[]byte) to avoid allocations.
• Explicitly ignored unhandled deferred errors (e.g., _ = ln.Close()) to satisfy errcheck linters.

Assumptions

• The standard log/slog package is the preferred way to log errors when centralizing error reporting in this project.
• The bufferPool size of 1<<15 is appropriate and doesn't need to be changed in this PR.

Alternatives Not Chosen

• Integrating Sentry directly in this PR was not chosen as it would expand the scope beyond the required refactoring limit and requires configuration not currently present.
• Fixing the infinite loop with a labeled break break Loop was not chosen, as returning nil is cleaner and achieves the same result of exiting the serve loop upon context cancellation.

How To Pivot

• If a different logging library (like zap or logrus) is preferred, simply update the implementation inside ReportError in error.go to use the chosen library. No call sites will need to be updated.

Next Knobs

• error.go: Modify the ReportError function to add metrics, send to Sentry, or change the log level.
• tcp.go:bufferPool: Adjust the buffer size inside the sync.Pool if benchmarking reveals a more optimal size.

---

PR created automatically by Jules for task 4666474882042231051 started by @lucasew

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.