DBSC: separate browser-advertised endpoint URLs from local handler paths

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

PR #67388 intentionally models `RegistrationPath` and `RefreshPath` as nonempty application-local `PathString` values. The handler owns those local request paths, prepends `Request.PathBase` when advertising them, and derives refresh-cookie scoping from the local refresh path. This is a safe, conformant server subset, but it cannot represent every URL reference allowed by DBSC.

The W3C DBSC protocol and Chromium support secure same-site absolute registration and refresh URLs. The current model therefore cannot cover a sibling endpoint origin, an alternate port, arbitrary public-to-local proxy path translation, or query-based routing.

### Describe the solution you'd like

Design separate browser-advertised registration and refresh URL-reference options while retaining local handler dispatch paths. Define precedence and consistency rules between the advertised references, local paths, `Request.PathBase`, and refresh-cookie path.

The design should address:

- HTTPS with an explicit localhost development exception, and rejection of user-info and fragments.
- Validation of every redirect hop before forwarding DBSC proof, session, or cookie data.
- Same-site checks using Public Suffix List/registrable-domain semantics.
- Cookie Domain, Path, Secure, and SameSite applicability across the advertised topology.
- Accepted Host restrictions and trusted forwarded scheme, host, and prefix configuration.
- A non-permissive CORS posture; endpoint reachability must not imply credentialed cross-origin API access.
- Interaction with `IncludeSite`, an explicit scope origin, `/.well-known/device-bound-sessions`, and Data Protection/ticket sharing between applications.
- Compatibility and migration behavior for the existing local `PathString` options.

Required coverage should include same-origin absolute URLs, secure same-site sibling origins, alternate ports, proxy-translated paths, query routing, invalid/cross-site/insecure destinations, redirects that change site or security, cookie applicability, PathBase behavior, host filtering, trusted forwarding, and multi-application Data Protection. The design requires a security/threat review before implementation.

This is related to, but separate from, #67827: advertised endpoint location controls where protocol requests are sent, while that issue controls subdomain registration requesting registrable-domain-root site scope. See also PR #67388.

Start by reading PR #67388 and the relationship to issue #67827 to understand the existing local PathString model and scope boundaries. Develop the advertised URL-reference design and complete the required validation, redirect, cookie, proxy, host, CORS, migration, and multi-application coverage, with a security/threat review before implementation.

Written by the indexing model from the issue text.