fix: wrap third-party resolver error with %w in challenge.go

[0dillon]

Closes #2

Summary

Changed the format string for wrapping the third-party client domain resolver error from %s to %w in challenge.go.

What changed

• In internal/auth/challenge.go, updated fmt.Errorf("%w: %s: %s", ...) to fmt.Errorf("%w: %s: %w", ...) where the third-party client domain resolver error is returned.

Key design decisions

• Wrapping this external/third-party error using %w is safe because the Resolver interface is provided by the caller/client. Exposing it so they can use errors.Is(err, TheirCustomError) maintains the proper boundary without leaking internal logic.
• Other SDK errors from txnbuild are intentionally kept as they are to avoid leaking go-stellar-sdk implementation details to the caller.

Acceptance-criteria checklist

• Review fmt.Errorf usages in challenge.go.
• Switch to %w where safe without exposing internal errors to the handler.
• Test that sentinel matching (errors.Is) remains intact.

Test output & Coverage result

PASS
coverage: 85.8% of statements
ok      github.com/0dillon/Anchorage/internal/auth      3.235s

Follow-ups

• None strictly required for this PR, though the other error wrappers in read.go and verify.go could also be systematically reviewed if desired.

Security note

• No sensitive configuration or cryptographic secrets are exposed in the error trace by this change.

Discrepancy note

• The issue stated that sentinel errors were wrapped using %s. They were actually already wrapped using %w (e.g., ErrClientDomainRejected). However, the internal error err (which the sentinel wraps) was flattened with %s. We updated this specific format string to %w to preserve the err identity.