refactor: make handle resolution methods return non-optional values

[nnabeyang]

This PR refactors the handle resolution methods in ATResolver to return non-optional values.

Previously, didForHandle(_:) and resolveHandle(_:) returned Optional values, requiring callers to handle nil cases. This change updates these methods to return non-optional String and ResolvedData types, delegating failure handling to Swift’s error handling mechanism (throws).

[mattmassicotte]

Thanks for taking a look at this. I'm always torn on stuff like this. Does "no did" mean throw or mean "nil"? I'm tempted to say that an Optional result does in fact make sense here. What do you think about that?

[nnabeyang]

@mattmassicotte Thanks for the feedback! I totally understand being torn on "throw vs nil" for this kind of domain logic.

The main motivation behind this PR was that, in the current implementation, didForHandle never actually returns nil—it either succeeds with a String or throws an error from underlying methods like didForDomain. The current String? type forces the caller to handle a nil case that never actually happens in the throwing path.

[mattmassicotte]

Sorry for taking so long here. You're right, the current implementation doesn't ever return nil. And I think that's actually a bug! It does not make sense that these methods should be forced to throw if a nonexistent handle is used as input.

I think the API is actually correct, and the implementation is the problem!

However, that's an issue for this PR. Do you have any interest in persisting here? I completely understand if you don't and I don't want to waste any more of your time on it.

[nnabeyang]

@mattmassicotte You're exactly right. Treating a nonexistent handle as a domain-level nil (rather than a system-level throw) makes perfect sense. I've updated the PR to implement this behavior.
a00cc7f
7190f28

[mattmassicotte]

This makes a lot more sense to me. Thanks so much for taking it on, and being patient while we figured out what the right solution was.

[mattmassicotte]

(The CI failure is unrelated. I think at least one successful run is sufficient to validate that the change is reasonable.)