docs(ai): move agent rules to ai/skills and add an AI development sandbox (#1498)

The sandbox provides an isolated Docker environment for AI-assisted development
(OpenCode + Claude Code + Qwen Code) against the local AkkudoktorEOS repository.

The sandbox does not protect the repository from harmful changes by the agent.
It limits what a misled agent can reach on the machine, but the agent can still
write any change into the repository.

Primary security defence is to check every change before it is run on the host.
Same holds for opening a pull request or updating one.

Additional changes

- Reduce AGENTS.md to the project summary, baseline rules, completion checklist,
  and an index of the skills.
- Add skills for the Python environment and REST API error responses.
- Add the development guide page docs/develop/ai.md: the AI coding
  workflow, how agents get the project rules from AGENTS.md and ai/skills,
  and how to use the sandbox (start, agent logins, project commands with a
  virtual environment outside the workspace, running EOS and EOSdash,
  GitHub access, persistent data, security model).
- Add a checklist for reviewing agent changes before pushing, starting with
  .git, which stays writable in the sandbox.
- Check out all text files with LF line endings (.gitattributes), also on
  Windows with core.autocrlf, so the sandbox scripts run in the container
  and git in the container agrees with git on the host. Batch files keep CRLF.
- Publish the ports of ai/compose.yaml on request (AI_SANDBOX_PORTS=1).
  docker compose run publishes them only with --service-ports. Off by
  default, so that several sandboxes can run in parallel.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

ai/skills/python-quality/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: python-quality
+description: Use when writing or modifying Python code. Enforces Ruff, mypy, typing and tooling conventions of this project.
+---
+
+# Python Quality and Type Checking
+
+These rules add to the rules for every change in `AGENTS.md` (typing,
+docstrings, naming, `assert`, logging, dependencies).
+
+- Follow the project's Ruff configuration for lint and format.
+- Keep compatible with the project's mypy configuration; do not add new type errors.
+- Prefer explicit, narrow types over `Any`.
+- Handle optional values and error cases explicitly.
+- Keep abstractions proportionate; avoid unnecessary complexity.
+- Use the project's configured tools; do not introduce competing formatters or
+  linters.