Drop dependency on github.com/pkg/errors

[alexandear]

Before this PR

The project depended on github.com/pkg/errors for wrapping and formatting errors. This adds an extra external dependency for functionality that modern Go provides in the standard library. Keeping it also increases maintenance surface and dependency churn.

After this PR

All usages of github.com/pkg/errors were replaced with standard-library error handling (fmt.Errorf("...: %w", err) and errors where needed), and the module dependency was removed from go.mod.

==COMMIT_MSG==
Drop dependency on github.com/pkg/errors
==COMMIT_MSG==

Possible downsides?

• If anyone relied on pkg/errors stack-trace formatting (for example, %+v behavior), that detail is no longer available from newly wrapped errors.
• Error message text changed slightly in some places, which could affect brittle string-matching tests or log parsers.

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Replace usage of github.com/pkg/errors with standard library equivalents

Check the box to generate changelog(s)

• Generate changelog entry

[bluekeyes]

Thanks for the PR. I discussed this with my team internally and I think it makes sense to remove the dependency on pkg/errors and that the loss of stack traces likely won't be a problem in this context.

Out of curiosity, was there any specific issue with pkg/errors that motivated you to submit this?

[changelog-app]

✅ Successfully generated changelog entry!

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

---

📋Changelog Preview

💡 Improvements

• Replace usage of github.com/pkg/errors with standard library equivalents (#543)

[alexandear]

Out of curiosity, was there any specific issue with pkg/errors that motivated you to submit this?

There's a Go proverb worth quoting here: "A little copying is better than a little dependency." If a dependency can be replaced with a few lines of code or with the standard library, it probably should be. Every dependency we remove is one less thing that can be compromised, the vendor tree gets smaller, and reviewing future dependency changes becomes easier. The benefits compound over time.