ci: actually run the test suites that exist in the tree

The panel ships 25 pytest tests and 2 vitest tests. Nothing executed them:
there was no job, no local dev loop, and nothing that would have noticed when
one of them rotted. They pass, and they are 8 seconds of work, which is the
argument for having them.

Both jobs mirror how the image is built rather than how a developer would run
them by hand: `npm ci` because that is what the Dockerfile does, so the tree
under test is the tree that ships, and requirements-dev.txt through uv, which
is now pinned like the other CI tools.

The backend job runs `python -m pytest`, not bare `pytest`. The tests import
`app.*` relative to the backend directory, and only the `-m` form puts the
working directory on sys.path.

ruff format --check joins ruff check in the lint job. It needed 0ae0df7 to be
addable, since ten files disagreed with the style ruff.toml has always
declared.

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

.gitea/workflows/ci.yaml

@@ -131,6 +131,11 @@ jobs:
         run: |
           ruff check .
 
+      - name: Check Python formatting with Ruff
+        shell: bash
+        run: |
+          ruff format --check .
+
   lint-yaml:
     runs-on: [self-hosted, linux, arch, homelab]
     timeout-minutes: 10
@@ -175,6 +180,60 @@ jobs:
 
           hadolint -c .hadolint.yaml "${dockerfiles[@]}"
 
+  test-backend:
+    runs-on: [self-hosted, linux, arch, homelab]
+    timeout-minutes: 15
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
+
+      # 25 tests over the panel's pydantic models, its auth flow, the SPA
+      # fallback and the Kubernetes client it shells out with. They existed and
+      # had never been executed by anything.
+      #
+      # Note that userbot/ is a subtree synced from forust/userbot, so a routine
+      # sync can turn this red on upstream's code. Unlike the shellcheck job,
+      # which skips that tree because style disagreements there are ours to
+      # lose, a failing test here is a real defect in a service we deploy.
+      - name: Run the panel backend test suite
+        shell: bash
+        run: |
+          set -euo pipefail
+          tools_dir="$(bash .gitea/workflows/install-ci-tools.sh uv)"
+          export PATH="$tools_dir:$PATH"
+
+          # A venv in a temp dir rather than a checked-out one: the runner is
+          # shared, and a leftover .venv would let a dependency the
+          # requirements no longer pin still satisfy an import.
+          venv="$(mktemp -d)/venv"
+          uv venv --quiet "$venv"
+          uv pip install --quiet --python "$venv/bin/python" \
+            -r userbot/panel/backend/requirements-dev.txt
+
+          # `python -m`, not bare `pytest`: the tests import `app.*` relative to
+          # the backend directory, which only works if the cwd is on sys.path,
+          # and only `python -m` puts it there.
+          cd userbot/panel/backend
+          "$venv/bin/python" -m pytest tests/ -q
+
+  test-frontend:
+    runs-on: [self-hosted, linux, arch, homelab]
+    timeout-minutes: 15
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
+
+      - name: Run the panel frontend test suite
+        shell: bash
+        run: |
+          set -euo pipefail
+          cd userbot/panel/frontend
+          # `npm ci`, not `npm install`, for the same reason the Dockerfile
+          # uses it: the lockfile is what makes the tree that gets tested the
+          # tree that gets shipped.
+          npm ci
+          npm test
+
   validate:
     runs-on: [self-hosted, linux, arch, homelab]
     timeout-minutes: 20