v2.0.6 — cloud key fetch survives /meshes 401/403

Fix

OrbitCloudClient.get_mesh() now treats a 401/403 on a key endpoint like a 404 — it falls through to the next candidate path (/meshes → /network_topologies → /networks) instead of aborting discovery with CloudAuthError.

By the time get_mesh() runs, login and /devices have already succeeded with the same token, so an auth-style rejection on a key endpoint is an account-schema mismatch, not an expired session. Newer-schema accounts (where /meshes returns 401 and keys are served from /network_topologies) previously failed setup with a misleading "invalid email or password" error despite valid credentials — they now complete discovery.

Backwards compatible: accounts where /meshes returns 200 are unaffected (first path still wins). Complements the WAF User-Agent fix (#6).

Full changelog: v2.0.5...v2.0.6

Thanks to @exactmike for the live-verified fix (#10).