refactor: revert CI image approach and use standard npm ci in workflows

The CI image approach with pre-installed dependencies doesn't work with Gitea Actions due to workspace mounting issues. When Gitea Actions runs a container job, it mounts the workspace at a specific path (e.g., /workspace/david/euchre_camp), which hides the container's /app directory where dependencies were installed.

Changes:
- Reverted pr.yml unit-tests to use node:20-alpine with npm ci
- Updated pr.yml acceptance-tests to use mcr.microsoft.com/playwright image with npm ci
- Updated test.yml to use node:20-alpine with npm ci
- Removed ci-image-builder.yml workflow
- Removed Dockerfile.ci and build-ci-image.sh
- Updated AGENTS.md and README.md to document the deprecation
- Updated justfile to remove CI image commands

The standard approach of running npm ci in each workflow is the recommended approach for Gitea Actions.

README.md

@@ -368,35 +368,27 @@ The application uses Gitea Actions for continuous integration and deployment:
    - Unit tests for quick feedback
    - Skips auto-generated version bumps
 
-3. **Release Workflow** (`.gitea/workflows/release.yml`): Runs on main branch pushes
-   - Version bumping and tagging
-   - Docker image building and testing
-   - Registry push and deployment
-
-4. **CI Image Builder** (`.gitea/workflows/ci-image-builder.yml`): Runs when dependencies change
-   - Automatically builds CI runner image with all dependencies pre-installed
-   - Triggered by changes to `package.json`, `package-lock.json`, or `Dockerfile.ci`
+ 3. **Release Workflow** (`.gitea/workflows/release.yml`): Runs on main branch pushes
+    - Version bumping and tagging
+    - Docker image building and testing
+    - Registry push and deployment
 
 ### CI Runner Image
 
-To avoid installing dependencies on every workflow run, we use a pre-built CI runner image:
+**Note:** The CI runner image approach has been deprecated for Gitea Actions workflows.
 
-**Dockerfile.ci** - Contains:
-- Node.js 20 Alpine
-- All npm dependencies pre-installed
-- Prisma client pre-generated
-- System tools (bash, git, python, make, g++)
+The original attempt to use a pre-built CI runner image with pre-installed dependencies encountered fundamental issues with how Gitea Actions handles workspace mounting. When Gitea Actions runs a container job, it mounts the workspace at a specific path (e.g., `/workspace/david/euchre_camp`), which hides the container's `/app` directory where dependencies were installed.
 
-**Automatic Rebuilding:**
-- The CI image is automatically rebuilt when `package.json` or `package-lock.json` changes
-- Images are tagged with commit SHA for traceability
-- Falls back to `node:20-alpine` if custom image is not available
+**Current Approach:**
+- Workflows use standard `node:20-alpine` or `mcr.microsoft.com/playwright` containers
+- Dependencies are installed via `npm ci` in each workflow run
+- This is the recommended approach for Gitea Actions
 
-**Manual Build:**
-```bash
-docker build -f Dockerfile.ci -t euchre-camp-ci:latest .
-docker run --rm euchre-camp-ci:latest node --version
-```
+**Why the CI image approach doesn't work:**
+1. Dockerfile.ci installs dependencies in `/app`
+2. Gitea Actions mounts workspace at `/workspace/david/euchre_camp`
+3. Workspace mount hides the `/app` directory
+4. Symlinks from `/app/node_modules` don't work because `/app` is hidden
 
 ### Database Strategy for CI
 - **CI Tests**: SQLite database (fast, no server required)
@@ -410,9 +402,6 @@ npm run test:run
 
 # Run acceptance tests with SQLite
 DATABASE_PROVIDER=sqlite DATABASE_URL=file:./prisma/ci.db npm run test:acceptance
-
-# Run tests in CI container (if built)
-docker run --rm -v $(pwd):/app -w /app euchre-camp-ci:latest npm run test:run
 ```
 
 ## Docker Deployment