Support configurable "priority" field for services, expose via DNS for RFC compliant behavior

#### Feature Description

Consul currently supports DNS SRV responses for services, and already exposes configurable `weights` that influence balancing among SRV records. However, the SRV `Priority` field does not appear to be configurable as a property of a service, and DNS responses appear to use a fixed priority value.

I would like Consul to support explicit configuration of the SRV `Priority` field on a per-service basis, similar in spirit to how `weights` is configurable today.

This would allow operators to express two distinct routing behaviors through standard SRV semantics as defined in [RFC 2782](https://datatracker.ietf.org/doc/html/rfc2782):

- **Priority**: strict preference / failover ordering between groups of endpoints
- **Weight**: proportional balancing among endpoints within the same priority group

This is useful because SRV-aware clients commonly interpret these fields differently:

- lower numeric `priority` is preferred first
- `weight` is only used among records with equal `priority`

With this feature, Consul could support DNS-driven active/passive, primary/secondary, or preferred/fallback service discovery patterns without requiring consumers to infer failover behavior from weight alone. And would allow for some of the most common patterns which are currently not expressible via the existing prepared query API without additional and complex dynamic service registration and manipulation of service and/or node tags/metadata.

This request is motivated in part by the current SRV construction path in `agent/dns.go`, where `Weight` is derived from service state/configuration while `Priority` is set statically. Making `Priority` service-configurable would allow Consul DNS responses to better represent intended traffic preference and failover behavior.

This may also help address overlapping needs discussed in:

- #1584 — `"Leader service" with DNS support`, simply setting the priority of the leader to a fixed lowest priority, while setting other instances of the service to a higher priority would resolve this issue.
- #2803 — `Prepared queries that include results from multiple DCs`, as an extension of the notion of simply allowing priority to be set to a static value in the service registration API, the concept could be extended to expose the "nearest N" value as used when defining prepared queries such that a client that manages its own failover based on RFC 2782 semantics
- #1088 — `DNS round-robin based on SRV weight/priority`, as an extension to this feature non SRV queries returning A/AAAA rrsets could have be configured to return the lowest priority non-empty (healthy instances) set for a given service.

While those issues are not identical, they all touch adjacent service-discovery and DNS-routing concerns that could be better expressed if SRV priority were explicitly configurable.

#### Use Case(s)

**Use case area:** Service Discovery

Example use cases include:

1. **Active/passive failover**
- Publish primary instances with lower priority
- Publish standby instances with higher priority
- SRV clients prefer primaries and only fall back when needed

2. **Cross-datacenter or cross-zone preference**
- Prefer local or primary datacenter/service instances
- Expose secondary or DR instances as fallback groups
- Preserve weighting only within each group

3. **Leader/preferred instance discovery**
- Prefer one instance or one class of instances for normal operation
- Allow fallback to other instances during outage or maintenance
- This overlaps conceptually with the needs described in #1584

4. **Prepared-query and multi-site service discovery**
- When multiple endpoint groups are returned, distinguish preferred groups from backup groups using SRV priority
- This overlaps conceptually with the routing/failover concerns in #2803

5. **Operational traffic shaping using standard DNS semantics**
- Use `priority` for strict ordering
- Use `weight` for balancing within equal-priority records
- This aligns directly with the request in #1088

A possible shape for this feature would be an optional per-service field such as `priority`, defaulting to the current behavior when unset for backward compatibility. And having similar semantics to `tags` or `weights` with regards to being able to be overridden at run time per service instance.

Start in agent/dns.go, where the issue identifies SRV construction and the static Priority value, then trace how service weights and per-service configuration reach that path. Define how an optional service priority should be configured and overridden while preserving current behavior when unset. Done means SRV responses expose the configured priority and retain weight-based behavior within equal-priority records.

Written by the indexing model from the issue text.