add deploy-stack skill; falco: fix hook-tamper condition, add three more post-incident rules

git-hook-tamper.yaml's condition used proc.exepath, which resolves to the
script interpreter's path (e.g. /bin/busybox) for shebang scripts, not the
script's own path - switched to proc.cmdline, which retains the originally
invoked path. Confirmed via live-testing both ways.

ssh-persistence/cloud-metadata-probe/db-spawned-process round out the
post-incident hardening pass with a few more incubating-ruleset adaptations.

falco/rules/db-spawned-process.yaml

@@ -0,0 +1,30 @@
+# Custom rule, adapted from falcosecurity/rules' Incubating ruleset (not
+# shipped in this Falco image). Generalizes the lesson from the gitea
+# log-poisoning RCE (a service's own process forking something unexpected)
+# to every other DB-backed service on this host - immich, firefly-iii,
+# romm, inbox-zero-db, etc. A database server forking a child process other
+# than itself is not normal and often follows a SQL injection attack.
+
+- list: db_server_binaries
+  items: [mysqld, postgres, sqlplus]
+
+- macro: user_known_db_spawned_processes
+  condition: (never_true)
+
+- rule: DB program spawned process
+  desc: >
+    A program related to a database server created an unexpected child
+    process (other than itself). This is not supposed to happen and often
+    follows SQL injection attacks - could indicate unauthorized data
+    extraction or tampering.
+  condition: >
+    spawned_process
+    and proc.pname in (db_server_binaries)
+    and not proc.name in (db_server_binaries)
+    and not user_known_db_spawned_processes
+  output: >
+    Database-related program spawned unexpected process
+    (user=%user.name command=%proc.cmdline parent=%proc.pname
+    container=%container.name image=%container.image.repository pid=%proc.pid)
+  priority: WARNING
+  tags: [database, process, mitre_execution]