Add camera rotation and optical parameters to projects (schema v23)

[tomaszmrugalski]

Summary

This PR adds support for storing camera rotation angle and optical imaging parameters (focal length, sensor resolution, pixel pitch) directly on project records. These values are auto-populated from the telescope's attached sensor at project creation time but can be overridden to model different optical configurations (e.g., focal reducers, binning). This enables the frontend to render sky visualizations without requiring a separate API call to the scopes endpoint.

Key Changes

Database Schema (v23)

• Added six new nullable columns to projects table:
  • rotation (FLOAT): camera position angle in degrees, East of North convention
  • focal (FLOAT): focal length in mm
  • resx, resy (INTEGER): sensor width and height in pixels
  • pixel_x, pixel_y (FLOAT): pixel pitch in micrometers
• Migration script back-fills existing projects from their telescope's attached sensor via JOIN

API Endpoints

• GET /api/projects and GET /api/projects/{id}: response now includes all six new fields
• POST /api/projects: accepts optional rotation, focal, resx, resy, pixel_x, pixel_y in request body; auto-populates from scope's sensor when omitted
• PATCH /api/projects/{id}: allows updating any of the six fields individually or clearing them with null

Backend Implementation

• Updated ProjectSchema, ProjectCreateSchema, and ProjectUpdateSchema marshmallow schemas with new fields
• Modified project creation logic to query telescope's focal length and attached sensor, then use those as defaults if not explicitly provided in request
• Updated SQL column selection queries and row-to-dict conversion to include new fields
• Updated CLI show_project and add_project commands to display and accept optical parameters

OpenAPI Documentation

• Added comprehensive field descriptions for all six new parameters in request/response schemas
• Documented auto-population behavior and override semantics

Tests

• Added 15 new test cases covering:
  • Explicit rotation in POST/PATCH
  • Rotation defaulting to null
  • Auto-population of optical params from sensor
  • Handling scopes without attached sensors
  • Explicit override of auto-populated values
  • Individual field updates via PATCH
  • Clearing fields with null
  • Presence of fields in GET responses

Documentation

• Added comprehensive implementation plan (doc/sky-visualisation-plan.md) detailing:
  • Backend schema and API changes (this PR)
  • Frontend component architecture for Aladin Lite integration (follow-up PR)
  • FOV calculation formulas
  • Corner coordinate computation for rotated rectangles
  • Integration points in project detail and all-projects sky map views

Implementation Details

• Optical parameters are denormalized by design: they represent the imaging setup as planned for this project, which may differ from the telescope's current configuration
• rotation defaults to NULL (not 0) to distinguish "not set" from "North up"
• The rotation convention matches FITS PA keyword and PixInsight plate-solve output (degrees East of North, 0–360)
• Auto-population uses a LEFT JOIN to handle scopes without attached sensors gracefully (all optical params become null)
• Explicit values in POST/PATCH body always override auto-populated defaults

https://claude.ai/code/session_01Mn5wvy2To8d95XVLTBcRXE