Backend runtime upgraded to Python 3.14 with exact dependency pinning (#57)

Signed-off-by: Cliff Hill <xlorep@darkhelm.org>

## Summary

Upgrades backend runtime baseline and dependency management for issue #10.

### Changes

1. **Python Baseline**: Updated from 3.13 to 3.14
   - Updated `backend/pyproject.toml` requires-python constraint
   - Updated `backend/pyrightconfig.json` pythonVersion
   - Updated all Dockerfile and CI references

2. **Dependency Pinning**: Switched to exact version pins in `backend/pyproject.toml`
   - All dev and runtime dependencies now use `==` instead of `>=`
   - `fastapi==0.120.2`, `uvicorn==0.38.0`
   - ruff, pyright, pytest suite pinned to current resolved versions
   - Regenerated `backend/uv.lock` under Python 3.14

3. **Startup Compatibility Guard** (TDD via RED→GREEN)
   - New `compatibility_status()` function evaluates runtime and pinned deps
   - Startup raises `RuntimeError` if policy fails
   - Implemented via FastAPI lifespan (non-deprecated) handler

4. **Compatibility Status Endpoint**
   - New `GET /compatibility` returns policy status, runtime version, and package checks
   - Shares single source of truth with startup validation

5. **Integration Tests**
   - Added failing-then-passing tests for startup guard and endpoint behavior
   - 100% coverage maintained

6. **Direnv Configuration**
   - Added `UV_PYTHON="3.14"` pin to repo `.envrc`
   - Ensures direnv creates/recreates venv with correct Python version

### Validation

- ✅ ruff format/check
- ✅ pyright strict (0 errors)
- ✅ pytest: 8 passed, 100% coverage (>=95 gate)
- ✅ pydoclint: pass
- ✅ xdoctest: pass

### Notes

- SQLAlchemy/SQLModel introduction deferred to next pass per scope
- Compatibility logic currently validates fastapi/uvicorn pins (runtime deps)
- Ready for container build validation and Renovate bot testing

Co-authored-by: copilotcoder <copilotcoder@darkhelm.org>
Reviewed-on: #57
Co-authored-by: Cliff Hill <xlorep@darkhelm.org>
Co-committed-by: Cliff Hill <xlorep@darkhelm.org>

docs/agents/domain.md

@@ -0,0 +1,19 @@
+# Domain Docs
+
+This repository uses a single-context domain documentation layout.
+
+## Layout
+
+- Context file: CONTEXT.md at repository root
+- ADR directory: docs/adr/
+- Context map: not used for single-context layout
+
+## Consumer Rules for Skills
+
+- Skills that need domain language should read CONTEXT.md first.
+- Skills that need historical architectural decisions should read docs/adr/.
+- If CONTEXT.md or docs/adr/ is missing, skills may proceed and propose creating missing files as follow-up work.
+
+## Scope
+
+Use this layout as the default for architecture, diagnosis, and planning workflows unless the repository migrates to a multi-context monorepo structure.

docs/agents/issue-tracker.md

@@ -0,0 +1,21 @@
+# Issue Tracker
+
+This repository uses Gitea issues as the canonical issue tracker.
+
+## Platform
+
+- Host: dogar.darkhelm.org
+- Repository: DarkHelm.org/plex-playlist
+- Tracker mode: GitHub-style issue workflow on Gitea
+
+## How skills should use this tracker
+
+- Read open and closed issues in this repository as the source of truth.
+- Create new issues in this repository when a skill generates implementation work.
+- Update existing issues with status, notes, and cross-references to branches and pull requests.
+- Reference issue IDs in branch names and PR descriptions using the PP- prefix convention.
+
+## Operational notes
+
+- Prefer repository issues over local scratch files for planning and tracking.
+- If automation tooling expects GitHub semantics, treat Gitea issues as equivalent for workflow purposes.

docs/agents/triage-labels.md

@@ -0,0 +1,23 @@
+# Triage Labels
+
+This repository uses the default label vocabulary for triage state transitions.
+
+## Canonical Role Mapping
+
+- needs-triage -> needs-triage
+- needs-info -> needs-info
+- ready-for-agent -> ready-for-agent
+- ready-for-human -> ready-for-human
+- wontfix -> wontfix
+
+## Role Semantics
+
+- needs-triage: Maintainer review required to classify and scope the issue.
+- needs-info: Waiting on reporter feedback or missing reproduction details.
+- ready-for-agent: Fully specified and safe for autonomous implementation.
+- ready-for-human: Requires human implementation or decision-making.
+- wontfix: Intentionally not planned for implementation.
+
+## Usage
+
+When moving issues through triage, apply exactly these strings to avoid duplicate or drifted label names.