"server certificate verification OK" but "ALPN, server did not agree to a protocol"
TLS is transport layer sucurity. In the above case that has succeeded, no problem.
From Wikipedia:
Application-Layer Protocol Negotiation (ALPN) is a Transport Layer Security (TLS) extension for application layer protocol negotiation. ALPN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner that avoids additional round trips and which is independent of the application layer protocols. It is needed by secure HTTP/2 connections, which improves the compression of web pages and reduces their latency compared to HTTP/1.x.
Since APLN is an extension of TLS, it implies that TLS is being used. Even if the server is not using ALPN, but some other earlier protocol, both protocols must be extensions of TLS, or they would be able communicate.
In the above verbose output, "ALPN," is a prefix indicating that the rest of the line is the status of ALPN negotiation by the client side.
Basic Auth is just referring the basic API key/password protocol. (Those were included in the curl command line, but not shown). Here is good comparison of Basic Auth vs OAuth:
One of the disturbing trends I’ve noticed over the past few years is that more and more API services are slowly ditching support for HTTP Basic Authentication (aka: Basic Auth) in favor of OAuth. ... Basic Auth gets a bad reputation for being “insecure”, but this isn’t necessarily true. There are several things you can do to ensure that your API service (secured by Basic Auth) is as secure as possible: Always run all requests over HTTPs. If you’re not using SSL, than no matter what authentication protocol you use, you’ll never be secure. Unless you’re using HTTPs, all of your credentials will be sent in plain-text over the wire: a horrible idea. ...
So there is no proof of downgrading from TLS - and I doubt it is possible. Adding the --tlsv1.2 flag to curl results in the same output.
Exactly what this line
* ALPN, server did not agree to a protocol
means is still a mystery, but I'm guessing it means either (1) not agreeing to hhtp2, or less likely (2) the client asked if it continue without authorization and was refused, and thereupon used authorization. A truly bad choice of language for diagnostic output. Google returns thousands of results for that literal expression.