Sync upstream (pubky 0.10) + fix Android TLS "Revoked" on pkarr's relay client

[jvsena42]

Two commits: the upstream sync, then the fix it does not cover. Both are needed — measured on-device, neither alone stopped the errors.

The bug

Loopky was reporting "You're offline" on every Pubky-reading screen, on devices with a working connection. Under it:

certificate was revoked: java.security.cert.CertPathValidatorException:
    Certificate does not specify OCSP responder
→ invalid peer certificate: Revoked
→ HTTP transport error: error sending request for url (https://_pubky.…)

rustls-platform-verifier hard-fails revocation checking on Android: Let's Encrypt no longer publishes an OCSP responder, Android's PKIXRevocationChecker only tries OCSP, and the crate's Kotlin half turns the resulting CertPathValidatorException into StatusCode.Revoked. The crate's own escape hatch for this is gated on BuildConfig.TEST, so it never applies to a shipped app, and 0.7.0 is the latest release and still carries the bug (their PR #179 is the pending real fix). There is no version to upgrade to.

Upstream pubky/pubky-core-ffi has this too — same rustls-platform-verifier = "0.7.0", same src/rustls_init.rs. Anyone shipping it on Android is exposed.

Commit 1 — sync to upstream@74fea50 (pubky 0.10)

pubky 0.10 builds its ICANN client with webpki roots and revocation off (icann_tls_config_without_revocation_check). That is half the fix.

• Source merged clean. One fork-only call site needed the 0.10 signature: put_bytes threads a client_id through signin, matching what upstream did to put/delete_file/sign_in/sign_up/start_auth_flow.
• Every conflict was a generated artifact, resolved by regenerating, not by picking a side — upstream's binaries are built from upstream's source and carry none of this fork's added functions. Android (4 ABIs, llvm-stripped to match upstream), iOS xcframework + Swift, and Python are all rebuilt from this tree.

Commit 2 — the half 0.10 does not reach

pkarr builds its relay HTTP client from reqwest's defaults, which on Android is still the platform verifier. After the bump alone the device logged 8 more Revoked failures, every one immediately after:

pubky::actors::pkdns: Resolving homeserver for public key … via PKARR

So _pubky.<key> resolutions that fell back to the relay kept dying. Resolutions the DHT answered succeeded — which is exactly why this presented as intermittent rather than total.

pkarr 7 exposes ClientBuilder::reqwest_client and pubky 0.10 exposes .pkarr(..), so the relay client gets the same treatment upstream gave the ICANN one. Reaching it means constructing through PubkyHttpClient::builder() + Pubky::with_client.

Dropping revocation checking is upstream's own choice for this problem, and the trade is narrow here: these are relay lookups of public, signed pkarr records, and the record's signature — not the transport — is what makes the answer trustworthy.

reqwest goes 0.12 → 0.13 to match: the client handed to pkarr is only type-compatible at the same crate version, and the fork used reqwest directly in exactly one place, so this removes a duplicate reqwest from the tree rather than adding one.

Verified on-device

Redmi Note 11, Android 13, release build, same account and navigation each time:

	ClassNotFound	"Revoked"	transport errors	result
before the AAR fix	42	—	many	every handshake failed
AAR fix only	0	8	3	Home failed to load
+ pubky 0.10 only	0	8	3	still failing (relay)
+ this PR	0	0	0	session resolves in 1.8 s, not 12

Not addressed

libpubkycore.so still has a GNU_RELRO segment aligned to 0x1, so it is not 16 KB page-size compatible. Pre-existing, and a Play blocker in its own right.