explain within-handler presentation preference

Handler-level presentation preference is carried by
map_order.payment_handlers; review on #657 noted the instrument grain
was uncovered. The order of the business's advertised
available_instruments array now carries the same suggestive
within-handler preference, earliest first: platforms SHOULD consider it
and MAY apply their own ordering, and the buyer-side context.payment[]
preference remains distinct with the platform arbitrating. Completes
handler-major presentation ordering at both grains.

Author: igrigorik

docs/specification/overview.md

@@ -1930,10 +1930,12 @@ profile and response envelopes (see
 [The `ucp` Protocol Namespace](#the-ucp-protocol-namespace)). The preference
 is suggestive: it communicates the business's preferred presentation —
 typically a conversion or risk judgment — and platforms **SHOULD** take it
-into account but **MAY** apply their own ordering. It is distinct from, and
-does not override, the buyer-side preference a platform submits in
-`context.payment[]` (buyer-preferred handlers, on the request side); the
-platform arbitrates between the two.
+into account but **MAY** apply their own ordering. The same suggestive
+preference applies within a handler: the order of the business's advertised
+`available_instruments` array communicates preferred instrument presentation,
+earliest first. It is distinct from, and does not override, the buyer-side
+preference a platform submits in `context.payment[]` (buyer-preferred
+handlers, on the request side); the platform arbitrates between the two.
 
 **Available Instrument Resolution:** Within each active handler, both the
 platform and the business independently advertise `available_instruments` — the