test(lifecycle): widen two waits that were stricter than the product

Both failed a gate run on a healthy node.

bitcoin-receive already tolerated WALLET_LOCKED, but its 180s window
starts when the TEST starts and the lnd restart that locks the wallet can
land partway in. On 2026-08-08 the restart hit 65s in and the wallet
unlocked at 2m25s (journal: lnd.service started 20:11:05, "wallet has
been unlocked without a time limit" 20:13:48) — 48s after the deadline
expired. The daemon's own unlock budget is ~10 min because opening the
channel and graph dbs takes minutes on a loaded box, so 180s was stricter
than the thing under test. Now 420s, ARCHY_LND_UNLOCK_SECS.

btcpay's start wait was 180s, but stopping btcpay DELETES the container
(quadlet renders --rm), so package.start is a full dotnet recreate rather
than a container start. Measured 52s on a quiet box; it exceeded 180s
during a gate run on the same node at load ~11. Now 300s,
ARCHY_BTCPAY_START_SECS.

Neither change masks a lifecycle fault: both paths were verified by hand
to complete correctly, just slower than the assertion allowed.

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

tests/lifecycle/bats/bitcoin-receive.bats

@@ -76,12 +76,21 @@ _lnd_running() {
   # transient code — REST unreachable, gRPC "waiting to start" (mapped to
   # LND_ERROR), wallet locked until the auto-unlocker gets through, or a
   # post-unlock sync phase. All of those are the node settling, not broken —
-  # retry up to 180s (run A caught WALLET_LOCKED, run B caught LND_ERROR
+  # retry until the deadline below (run A caught WALLET_LOCKED, run B caught LND_ERROR
   # while lnd was seconds into its restart; both self-healed within a couple
   # of minutes). Only LND_WALLET_UNINITIALIZED (no wallet — never self-heals)
   # fails immediately, and anything still erroring after the window fails
   # loudly below.
-  local deadline=$((SECONDS + 180)) err addr
+  # 420s, not 180s: the window starts when this TEST starts, but the lnd
+  # restart that locks the wallet can land partway into it. On 2026-08-08 the
+  # restart hit 65s in and the wallet unlocked at 2m25s (journal: lnd.service
+  # started 20:11:05, "wallet has been unlocked without a time limit"
+  # 20:13:48) — 48s after this deadline expired, so the test reported
+  # LND_WALLET_LOCKED on a node that was fine. The daemon's own unlock budget
+  # is ~10 min (UNLOCK_NOT_READY_ATTEMPTS=600) because opening the channel and
+  # graph dbs takes minutes on a loaded box, so anything under that is the test
+  # being stricter than the product it is testing.
+  local deadline=$((SECONDS + ${ARCHY_LND_UNLOCK_SECS:-420})) err addr
   while :; do
     run rpc_call lnd.newaddress
     [ "$status" -eq 0 ]

tests/lifecycle/bats/btcpay.bats

@@ -88,7 +88,12 @@ btcpay_components=(
   run rpc_result package.start '{"id":"btcpay-server"}'
   [ "$status" -eq 0 ]
 
-  run wait_for_container_status btcpay-server running 180
+  # 300s, not 180s: stopping btcpay DELETES the container (quadlet renders
+  # --rm), so this is a full recreate of a dotnet image, not a container start.
+  # Measured 52s on a quiet box; it blew past 180s during a gate run on the
+  # same node at load ~11. That is the app being slow under contention, not a
+  # lifecycle fault.
+  run wait_for_container_status btcpay-server running "${ARCHY_BTCPAY_START_SECS:-300}"
   [ "$status" -eq 0 ]
 }
 
@@ -100,7 +105,7 @@ btcpay_components=(
   run rpc_result package.restart '{"id":"btcpay-server"}'
   [ "$status" -eq 0 ]
 
-  run wait_for_container_status btcpay-server running 180
+  run wait_for_container_status btcpay-server running "${ARCHY_BTCPAY_START_SECS:-300}"
   [ "$status" -eq 0 ]
 }