fix(drone-dep): correct gitea admin create flag + dep deploy counter

Two issues found during first manual harness run:

1. gitea `--must-change-password false` (space form) leaves a pending
   password-change for the ci_admin user, blocking the OAuth2 API call.
   Fix: use `--must-change-password=false` (equals form, required by
   gitea's BoolFlag with default=true).

2. dep deploy_app() calls incremented the DG4.1 "one deploy per run"
   counter, causing a false violation when gitea dep + drone both deploy.
   Fix: lifecycle.deploy_app gains _count_deploy=True param (default
   backward-compat); deps_mod.deploy_deps passes _count_deploy=False so
   only the recipe-under-test counts toward DG4.1.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

runner/harness/deps.py

@@ -80,9 +80,10 @@ def deploy_deps(
     for dep in deps:
         domain = dep_domain(parent_recipe, pr, ref, dep)
         print(f"  dep: deploying {dep} -> {domain}", flush=True)
-        # NB: each dep_app gets a fresh deploy_count entry only on `_record_deploy` which fires
-        # inside `lifecycle.deploy_app`. For Phase 2 the deploy-count guard (DG4.1) counts the
-        # parent + its deps as distinct install events — by design, since each is a separate app.
+        # Dep deploys do NOT count toward the DG4.1 "one deploy per run" invariant — that
+        # contract covers the recipe-under-test only; each dep is a supporting service, not the
+        # subject of the test. Pass _count_deploy=False so the main recipe's single-deploy
+        # assertion isn't distorted by the number of deps declared.
         dm = meta_for.get(dep) or meta_mod.load(dep)
         lifecycle.deploy_app(
             dep,
@@ -90,6 +91,7 @@ def deploy_deps(
             secrets=True,
             deploy_timeout=int(dm.DEPLOY_TIMEOUT),
             meta=dm,
+            _count_deploy=False,
         )
         try:
             lifecycle.wait_healthy(