Include aria-label as part of the Declarative API's toolparamdescription sources

[sawyer-stripe]

According to these docs: When toolparamdescription isn't set the browser uses the content within the associated <label> and skips descendants that are labelable. If there isn't a label, the browser refers to the aria-description.

Some existing sites use aria-label in place of <label> for some fields and actions. It would be helpful if aria-label was included in the determination of the toolparamdescription value, for instance, in order of priority:

1. <label>
2. aria-label
3. aria-description

[mlmrx]

The aria-label-only case is worth covering, but I think defining a new <label> → aria-label → aria-description priority would make the generated schema disagree with the control's accessibility semantics.

The Accessible Name and Description Computation already handles these sources and gives aria-labelledby precedence, then aria-label, then the host-language label. In particular, an explicit aria-label can intentionally override a visible <label>, while the proposed order would do the opposite and would omit aria-labelledby entirely. The same specification has a separate accessible-description computation, where aria-describedby precedes aria-description.

A more interoperable direction may therefore be to define the fallback in terms of the control's computed accessible name (and, if needed, its computed accessible description), rather than reading individual ARIA attributes in a WebMCP-specific order. That would also give #66's multiple-label case and aria-labelledby a defined result.

There is still a schema-mapping decision to make: #67 asks whether the short label/accessibility name belongs in JSON Schema title rather than description, while the longer accessible description maps more naturally to description. Since the declarative synthesis algorithm remains a TODO in #210, I don't think a code PR is safe until that mapping is resolved.

[sawyer-stripe]

define the fallback in terms of the control's computed accessible name

Yes, this is a better way of describing the behavior I'd be expecting (sorry, mixed up the suggested order in my original ticket).