v1.8.2

• اصلاح log level در UI binary (Windows + Android) (#401): قبلاً mhrv-rs-ui (و Android) فیلتر tracing رو فقط از RUST_LOG env var یا default info,hyper=warn می‌خوند — مقدار log_level در config.json در عمل ignore می‌شد. فرم UI combobox log_level داشت ولی هیچ‌جا به subscriber اعمال نمی‌شد. حالا precedence اینه: RUST_LOG (اگر set باشد) > config.log_level > info,hyper=warn. علاوه بر این Save در UI الان log level رو live اعمال می‌کنه (بدون نیاز به restart) از طریق reload handle. CLI mhrv-rs از قبل درست کار می‌کرد — این فقط fix UI bin بود.
• پیغام تشخیص decoy ملایم‌تر — به‌جای assert AUTH_KEY mismatch، چهار علت ممکن enumerate می‌کنه (#404): @w0l4i گزارش داد همان script_id گاهی decoy و گاهی موفقیت برمی‌گرده در یک دقیقه — یعنی NOT AUTH_KEY mismatch (اگر بود ۱۰۰٪ fail می‌گرفت). تحقیق نشون داد body string "The script completed but did not return anything" اختصاصی به decoy v1.8.0 ما نیست — Apps Script همان body رو در ۴ سناریو برمی‌گردونه: (۱) AUTH_KEY mismatch (decoy ما، intentional)، (۲) Apps Script execution timeout یا quota tear، (۳) Google-side internal hiccup، (۴) ISP-side response truncation (#313 pattern). Error message v1.8.1 false positive داشت در سناریو ۲-۴. حالا پیغام: "got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch, (2) Apps Script execution timeout/quota tear, (3) Apps Script internal hiccup, (4) ISP-side response truncation. Set DIAGNOSTIC_MODE=true to disambiguate (1) — only AUTH_KEY mismatch returns this body in diagnostic mode." کاربر action درست رو کشف می‌کنه.

• Fix log level on the UI binary (Windows + Android) (#401): previously mhrv-rs-ui (and Android, which uses the same JNI path) installed its tracing filter from RUST_LOG only — falling back to info,hyper=warn when unset. The log_level field in config.json was effectively ignored, even though the UI form has a combobox that writes to it. The CLI binary (mhrv-rs) read config.log_level correctly via init_logging(); only the UI binary was broken. New precedence: RUST_LOG (explicit override) > config.log_level (what the user picked in the form) > info,hyper=warn (default). The Save button now also reinstalls the filter live via a tracing_subscriber::reload::Handle, so users don't need to restart for a level change to take effect. RUST_LOG still wins if set at boot — explicit override beats config in both directions.
• Soften the v1.8.1 decoy detection error message — enumerate four candidate causes instead of asserting AUTH_KEY mismatch (#404): @w0l4i reported the same script_id mixing decoy ERROR with successful batches inside a one-minute window — which rules out AUTH_KEY mismatch as the cause (a real mismatch fails 100% of batches against that deployment, never succeeds intermittently). Investigation showed the body string "The script completed but did not return anything" is not unique to our v1.8.0 bad-auth path — Apps Script itself returns the same body in three other unrelated cases: (2) Apps Script execution timeout or per-100s quota tear, (3) Google-side internal runtime hiccup, (4) ISP-side response truncation mid-flight (the #313 pattern). The v1.8.1 error message was a false positive in scenarios 2-4. The v1.8.2 message now reads: "got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode." Users now have an actionable narrowing procedure instead of a confidently-wrong assertion.

Full Changelog: v1.8.1...v1.8.2