v1.4.1: Test Relay aware of Full mode + ship missing mipsel artifact

Patch release covering:

- #160 (deniz_us): Test Relay returned Google datacenter IPs even in
  Full Tunnel mode, because test_cmd::run unconditionally used
  fronter.relay() (apps_script path) regardless of configured mode.
  The user's tunnel-node was actually working — whatismyipaddress.com
  in their browser showed the correct VPS IP — but Test Relay
  contradicted it. Now Test Relay refuses cleanly in Full mode with
  a clear message and points users at the right verification path.
  A real Full-mode test through the tunnel mux is enhancement-tracked.

- mhrv-rs-openwrt-mipsel-softfloat artifact lands natively (commit
  6a0d45d). v1.4.0 had a build break on the 32-bit MIPS target due to
  PR #153's std::sync::atomic::AtomicU64 import — switched to
  portable_atomic::AtomicU64 which is already the project's
  convention for that reason. The artifact was hot-published to the
  v1.4.0 release page via workflow_dispatch yesterday; v1.4.1 ships
  it the normal way.

91 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: therealaleph

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "mhrv-rs"
-version = "1.4.0"
+version = "1.4.1"
 edition = "2021"
 description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
 license = "MIT"

Cargo.toml

@@ -14,8 +14,8 @@ android {
         applicationId = "com.therealaleph.mhrv"
         minSdk = 24 // Android 7.0 — covers 99%+ of live devices.
         targetSdk = 34
-        versionCode = 136
-        versionName = "1.4.0"
+        versionCode = 137
+        versionName = "1.4.1"
 
         // Ship all four mainstream Android ABIs:
         //   - arm64-v8a      — 95%+ of real-world Android phones since 2019

android/app/build.gradle.kts

@@ -0,0 +1,6 @@
+<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
+• رفع گمراه‌کنندگی دکمهٔ Test Relay در حالت Full Tunnel ([#160](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/160)): قبلاً وقتی mode روی `full` بود، Test Relay بی‌سر و صدا از مسیر apps_script استفاده می‌کرد و IP دیتاسنتر گوگل رو نشون می‌داد — که با IP واقعی tunnel-node کاربر متفاوت بود و این تناقض گیج‌کننده بود. حالا در حالت `full`، Test Relay صریحاً پیغام میده که این دکمه برای حالت Full پشتیبانی نمی‌کنه و راهنمایی می‌کنه که برای تست واقعی، مرورگر رو از طریق پروکسی محلی به whatismyipaddress.com ببرید. تست واقعی Full mode از طریق tunnel mux در ریلیزهای آینده اضافه میشه
+• انتشار آرتیفکت `mhrv-rs-openwrt-mipsel-softfloat.tar.gz` که در v1.4.0 بیلد نشده بود: PR #153's connect_data instrumentation از `std::sync::atomic::AtomicU64` استفاده می‌کرد، که روی هدف 32-بیتی MIPS (`mipsel-unknown-linux-musl`) موجود نیست. تغییر به `portable_atomic::AtomicU64` (که بقیهٔ کد به همین دلیل ازش استفاده می‌کنه) و انتشار از طریق workflow_dispatch جدید — همون آرتیفکت روی صفحهٔ ریلیز v1.4.0 هم اضافه شد
+---
+• Fix misleading Test Relay button behaviour in Full Tunnel mode ([#160](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/160)): when mode was set to `full`, Test Relay used to silently fall through to the apps_script code path and report a Google datacenter IP — which contradicted what the user actually saw in their browser via their tunnel-node, and looked like the relay was broken when it wasn't. Now in `full` mode, Test Relay returns a clear error explaining that this button isn't wired for full mode, with a recommendation to verify by loading whatismyipaddress.com through the local proxy. A real Full-mode test (via the tunnel mux) is on the queue
+• Publishes the `mhrv-rs-openwrt-mipsel-softfloat.tar.gz` artifact that failed to build in v1.4.0: PR #153's connect_data instrumentation imported `AtomicU64` from `std::sync::atomic`, which doesn't exist on 32-bit MIPS (`mipsel-unknown-linux-musl` for OpenWRT routers). Switched to `portable_atomic::AtomicU64` (already used elsewhere in the codebase for the same reason). The artifact was re-published to the v1.4.0 release page directly via the new workflow_dispatch path, and is shipped natively in v1.4.1