Stop device:launch crying wolf on release builds

A release APK is not DEBUGGABLE, so Capacitor never enables web-contents
debugging and the devtools socket is never opened. page_loaded waited for that
socket regardless, so it reported "renderer denied" three times for a healthy
app, force-stopping and restarting it on each retry. It now branches: debug
builds still wait for the page to parse; release builds check the process
survived with no denial against our package, and say the page load is assumed
rather than claiming a verification that is not possible over adb.

The failure diagnostic was unfiltered and unbounded, so it printed other apps'
denials from minutes earlier. It is now scoped to our package and to the
current launch.

Also fixes keep-awake, which still ran the "usb" form that CLAUDE.md had
already recorded as ineffective on this AC-charging phone, and corrects the
documented value: "true" measures as 15 here, not 7.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -76,7 +76,7 @@ Device notes), but nothing on screen can be verified through a lockscreen and
 | Command | What it does |
 |---|---|
 | `npm run device:keep-awake` | Stay awake while charging. Do this at the start of a session. |
-| `npm run device:launch` | Check awake/unlocked, force-stop, start, wait for the page to actually parse |
+| `npm run device:launch` | Check awake/unlocked, force-stop, start, wait for the page (debug builds) |
 | `npm run device:awake` | Just the check — prints a loud warning if locked |
 | `npm run device:sleep-normal` | Revert the stay-awake setting when finished |
 
@@ -84,6 +84,22 @@ Device notes), but nothing on screen can be verified through a lockscreen and
 starts fine even when the renderer was denied. On failure it prints the
 `AppBootManager` denial lines rather than leaving a blank window to puzzle over.
 
+**On a release build it cannot do that, and says so.** A release APK is not
+`DEBUGGABLE`, so Capacitor never calls `setWebContentsDebuggingEnabled` and
+`webview_devtools_remote_<pid>` is never opened — the page simply cannot be
+inspected over adb. Demanding that socket anyway made the helper report
+`renderer denied` three times for a perfectly healthy app, force-stopping and
+restarting it each time. It now checks that the process survived and that
+nothing denied *our* renderer, then prints `page load assumed, not verified`. A
+blank grey window and a working one are genuinely indistinguishable from here,
+so that wording is the honest limit, not hedging.
+
+The denial grep is filtered by package and bounded to the current launch
+(`logcat -d -T`, timestamp from `adb shell "date +'%m-%d %H:%M:%S.000'"` — the
+format must be one quoted argument or toybox `date` rejects it). Unfiltered, it
+printed `com.xiaomi.wearable` denials from minutes earlier and sent one session
+chasing a denial that had never happened to us.
+
 It also reads the pid *after* starting the app. `adb install -r` kills the
 running process, so a pid captured earlier points at a dead process and the
 devtools socket lookup fails while the app itself is healthy — that produced one
@@ -266,8 +282,10 @@ beats an afternoon of synthetic input.
 
 **Stay awake needs `svc power stayon true`, not `usb`.** The `usb` form writes
 `stay_on_while_plugged_in = 2`, and this phone charges over AC (`USB powered:
-false`), so it silently never engages — `mStayOn` stays false. `true` writes 7
-(any source) and works. The screen timeout is separate and was 30s:
+false`), so it silently never engages — `mStayOn` stays false. `true` sets every
+charging-source bit and works; measured as **15** here (AC|USB|wireless|dock),
+not the 7 an earlier note claimed — 7 predates dock charging. The screen timeout
+is separate and was 30s:
 
 ```
 adb shell svc power stayon true