[Feature Enhancement]: Wire `ATIdentityProtocol.resolvePDSEndpoint(from:)` into PDS-served wrappers

[KC-2001MS]

Summary

Implement an API that resolves a PDS endpoint from a target did, and call it from the two wrappers that currently route to a hardcoded bsky.social host.

Pain points

For the session holder we already know the PDS via session.serviceEndpoint. For an arbitrary target did (someone else's repo) there is no equivalent today, so these wrappers send their request to a fixed Bluesky-operated host instead of the PDS that actually hosts the target repo.

The scaffold for this was already added in #215 (2025-08-22) — public protocol ATIdentityProtocol { func resolvePDSEndpoint(from did: String) async throws -> String } — but no wrapper invokes it, and the affected call-sites still carry the marker:

// TODO: Change this back to "\(self.pdsURL)" once ATIdentityProtocol has been implemented.

Affected wrappers (lexicon-declared "implemented by PDS", accept an arbitrary did / repo, carry the TODO):

File	Method
ComAtprotoRepoDescribeRepoMethod.swift:36	describeRepository(_:)
ComAtprotoRepoListRecordsMethod.swift:43	listRecords(from:collection:...)

Considered Alternatives

• Replace the hardcoded host with session.serviceEndpoint. Correct only when did == session.sessionDID. Cross-repo reads (e.g. fetching another user's profile record) would then target the caller's PDS, which does not host the target repo, and fail. That is a regression versus today's behaviour, which at least covers entryway-managed cross-repo reads.
• Leave the hardcoded bsky.social fallback in place. This is the current state. It works via entryway proxying, but that behaviour is a Bluesky infrastructure implementation detail, not an AT Protocol guarantee, and it does not cover self-hosted PDSes.

Is this a breaking change?

No

Additional Context

• Closed predecessor: [Bug]: com.atproto.repo.listRecords sent to the wrong API server #215.
• Scaffold: Sources/ATProtoKit/Utilities/ATIdentityProtocol.swift.
• In-source TODO markers: ComAtprotoRepoListRecordsMethod.swift:42, ComAtprotoRepoDescribeRepoMethod.swift:35.

[MasterJ93]

So, my ideal solution is to simply have ATIdentityTools handle this. However, that is a relatively large package, and I don't want people to use it if they don't want to. I say "relatively large" as in, it shouldn't take more than 10 MB, but that might just be a dealbreaker for some developers.

I'm thinking that we would have a "mini" identity method that can check for something like this, and then allow developers to install other packages (such as ATIdentityTools) if so desired. But I'm willing to hear what you think of this.

[KC-2001MS]

Keeping the heavier identity work opt-in makes sense to me. As I understand it, resolving the PDS from a did is basically just hitting a fixed URL and reading a key out of the returned JSON — pretty lightweight, no session involved — so a built-in mini method feels like a reasonable fit, with ATIdentityTools still there for anyone who needs the fuller handling. The direction sounds good to me.

[MasterJ93]

Would it be possible for you to create a PR for this? If you are able to do so, I'd be happy to review it and share feedback on anything that might need to be changed. I hope that, with your help, we can resolve this issue together.

Of course, please don't feel pressured to do this. If creating a PR would be too inconvenient for you, then I'll do my best to make time to work on it myself.

[MasterJ93]

I'll be closing the issue now since the PR has been merged.