Feature: Add Native On-Chain .skr Name Resolution (Transfer + Receive) for Seeker Users

[lopeselio]

Is your feature request related to a problem? Please describe.
With recent work in this repo focused on Solana Mobile Wallet Adapter support for Seeker, it makes sense to improve identity UX for the same audience by adding native .skr resolution in the SDK.

A large and growing number of Seeker users interact with apps built on Solana Unity SDK, including games like Cryptara Conquest. In these experiences, users should be able to transfer assets, complete purchases, and trade with other players using human-readable .skr ANS names (AllDomains), instead of manually copying and pasting wallet addresses.

This would significantly reduce friction, improve usability on mobile, and better align the SDK with how Seeker users actually interact on-chain.

The Unity sample wallet currently expects a raw base58 address for transfers and does not natively resolve .skr names on-chain. This creates friction for Seeker users who use .skr identities, and causes transfer failures when a domain name is entered directly.
Also, wallet display in the receive flow only shows public keys, so users cannot easily verify their .skr identity in-app.
A backend resolver workaround exists, but it introduces deployment/runtime dependency and is not ideal for mobile sample usage.

Describe the solution you'd like
Add native on-chain .skr resolution support in the Unity sample wallet so no backend is required.
Specifically:

• Transfer flow: support .skr -> wallet address resolution before transaction submission.
• Receive flow: support wallet address -> .skr reverse lookup for display.
• Handle wrapped-domain ownership correctly (if name record owner is an NFT record PDA, resolve to the actual NFT holder wallet).
• Use Mainnet for .skr name resolution queries while keeping transaction cluster behavior unchanged.

Describe alternatives you've considered

• Local backend resolver (@onsol/tldparser with /resolve-domain and /resolve-address)
• Hosted backend resolver endpoint
• Keeping base58-only transfer input and asking users to manually resolve names externally
  These alternatives either add infra dependency/cost or reduce UX quality for Seeker/mobile users.

Additional context

• On-device testing (Seeker) shows this feature is needed for practical .skr transfers.
• A naive resolution approach can fail for wrapped domains; wrapped owner resolution is required for correctness.
• Desired UX:
  • Valid .skr resolves and transfer proceeds.
  • Invalid/nonexistent .skr shows a clear error (Unable to resolve <domain>) and does not submit.
  • Receive screen displays .skr when available, with public key fallback.

cc: @Kuldotha @Woody4618 @GabrielePicco