Use registration numbers instead of CUIDs in shareable dog URLs

[asku1990]

Problem

Public/admin dog-related URLs currently expose internal CUID dog IDs in places such as dog profile links. These links are not user-friendly and are less stable across imports/restores than registration numbers.

Goal

Migrate shareable dog URLs to use registration numbers as the public identifier, while keeping internal CUIDs as implementation details after server-side resolution.

Scope

• Public dog profile links from search results should use registration number URLs instead of row.id/CUID.
• Public dog profile loading should resolve DogRegistration.registrationNo -> Dog.id before loading the existing profile data.
• Admin/virtual-pairing shareable URL state should use registration numbers for selected sire/dam, not dog IDs.
• Keep existing CUID-based URLs working during migration, either as supported legacy routes or redirects, so old links do not break.
• Prefer query params for registration numbers where path params would be risky because registration numbers can contain /.

Suggested URL shapes

• Dog profile: /beagle/dogs/profile?reg=FIN18665%2F07
• Virtual pairing: /admin/dogs/virtual-pairing?sire=FIN18665%2F07&dam=FIN12562%2F97&sp=9

Acceptance Criteria

• Search result dog profile links no longer expose CUIDs.
• Shared/reloaded dog profile URL resolves by registration number and loads the same dog.
• Shared/reloaded virtual-pairing URL restores sire, dam, generation depth, and recalculates the same result.
• Existing /beagle/dogs/[dogId] links continue to work or redirect to the registration-number URL.
• Tests cover registration-number profile resolution, URL generation, and legacy CUID compatibility.
• Documentation/changelog is updated if user-visible routing changes are released.

Notes

Registration numbers are unique through DogRegistration.registrationNo; resolving aliases to the same dog is acceptable. Internally, services can continue using dog IDs after resolution.