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/ssh-persistence.yaml

@@ -0,0 +1,34 @@
+# Custom rule, adapted from falcosecurity/rules' Incubating ruleset (not
+# shipped in this Falco image - only the Stable ruleset ships by default).
+# Added after research into what else might be useful post-incident: neither
+# the gitea/xmrig nor gitea log-poisoning incidents involved SSH-key
+# persistence, but it's the textbook next move after any RCE, and gitea
+# itself has SSH access (port 222) making this directly relevant here.
+
+- list: ssh_binaries
+  items: [
+    sshd, sftp-server, ssh-agent,
+    ssh, scp, sftp,
+    ssh-keygen, ssh-keysign, ssh-keyscan, ssh-add
+  ]
+
+- macro: user_ssh_directory
+  condition: (fd.name contains '/.ssh/' and fd.name glob '/home/*/.ssh/*')
+
+- rule: Adding ssh keys to authorized_keys
+  desc: >
+    After gaining access, attackers can modify the authorized_keys file to
+    maintain persistence on a victim host. Detects any write to an
+    authorized_keys file under a user's .ssh directory or /root/.ssh,
+    by a process that isn't one of ssh's own binaries.
+  condition: >
+    open_write
+    and (user_ssh_directory or fd.name startswith /root/.ssh)
+    and fd.name endswith authorized_keys
+    and not proc.name in (ssh_binaries)
+  output: >
+    Adding ssh keys to authorized_keys
+    (user=%user.name file=%fd.name command=%proc.cmdline
+    container=%container.name image=%container.image.repository pid=%proc.pid)
+  priority: WARNING
+  tags: [ssh, persistence, mitre_persistence]