fix(drone-dep): revert _count_deploy=False — dep deploys must count for DG4.1

The DG4.1 formula in run_recipe_ci.py is:
  expected_deploy_count = 1 + deps_deployed_count

So when gitea dep deploys, the expected count becomes 2 (1 recipe + 1 dep).
The _count_deploy=False fix made dep deploys NOT count, giving actual=1 vs
expected=2 → DG4.1 violation even though the run was correct.

Original error "deploy-count 2 != 1" was because deps_state was empty when
the DG4.1 check ran (provisioning had failed), giving expected=1 while count
was already 2 from an early dep deploy. The proper fix is for _provision_deps
to succeed (which it now does), not to suppress counting.

Revert _count_deploy=False in deps.py; update docstrings for clarity.

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

runner/harness/lifecycle.py

@@ -254,8 +254,10 @@ def deploy_app(
     past the 900s default. abra's INTERNAL TIMEOUT (recipe's TIMEOUT env, default 300s) is set via
     EXTRA_ENV; this is the Python subprocess wrapper's timeout so abra doesn't get SIGKILLed mid-deploy.
 
-    `_count_deploy`: set False for dep deployments — the DG4.1 "one deploy per run" invariant
-    counts ONLY the recipe-under-test, not its install-time deps (deps_mod.deploy_deps)."""
+    `_count_deploy`: internal escape hatch — set False to skip incrementing the DG4.1 deploy
+    counter (e.g. for test fixtures that call deploy_app without participating in a real run).
+    Normal orchestration should always use the default True — dep deploys count too (the DG4.1
+    formula is `expected = 1 + deps_count`, so deps MUST be counted; see run_recipe_ci.py)."""
     if meta is None:
         meta = meta_mod.load(recipe)
     if _count_deploy: