Clear the stale Chrome singleton lock at browser boot (#76)

Co-authored-by: Sulthan Zaki <sultankiki05@gmail.com>
Co-committed-by: Sulthan Zaki <sultankiki05@gmail.com>

chrome/entrypoint.sh

@@ -77,7 +77,7 @@ start_browser() {
 		--no-first-run \
 		--no-default-browser-check \
 		--disable-gpu \
-		about:blank >/dev/null 2>&1 &
+		about:blank >/dev/null &
 	printf '%s\n' "$!" >"$pid_file"
 }
 
@@ -140,6 +140,9 @@ connection() {
 			result=$?
 		fi
 	else
+		# The client only ever sees a bare connection reset here, so this is
+		# the sole record that the browser, not the network, was the problem.
+		echo "browser did not come up; dropping connection" >&2
 		result=1
 	fi
 	finish_connection
@@ -174,6 +177,16 @@ for marker in "$connections_dir"/*; do
 done
 rm -f "$pid_file" "$last_use_file"
 
+# Chrome's singleton lock names the hostname and pid that took it, and a
+# container rebuild changes both — so a Chrome killed uncleanly (OOM, docker
+# kill) leaves a lock the next container reads as "another computer holds this
+# profile" and refuses to start behind, permanently, with the only symptom a
+# bare connection reset at 9222. Clearing it here is safe precisely because
+# container_name pins this volume to one container: nothing can be holding the
+# profile at the moment this line runs. The lock is process state; the
+# clearance cookies it sits beside are not, and are left alone.
+rm -f "$profile"/Singleton*
+
 # Chrome binds DevTools to loopback and silently ignores
 # --remote-debugging-address. socat remains the network front-end, but each
 # accepted connection now starts a browser on demand and is tracked by a