feat(domy): przypisanie do domu przez wyrocznię + poprawki układu strony

ETAP 5, część pierwsza: assign_house pod wyrocznią (swe_house_pos).
Osobny rodzaj błędu niż same cuspy — i od razu jeden znalazł.

BŁĄD: assign_house szło ZAWSZE do przodu. Przy dużych szerokościach systemy
dzielące koła wielkie mają kolejność domów ODWRÓCONĄ (przy φ=−84,3° cusp domu I
wypada na 174,2°, a domu II na 165,3°) — co nie jest usterką, bo wyrocznia zwraca
dokładnie te same wartości. Suma przeskoków „do przodu" wychodziła 3960° zamiast
360°, czyli każdy krok obchodził koło dookoła. Planety lądowały w złych domach
dla regiomontanusa, campanusa i topocentrica: 9,7-12,5% przypadków. Błąd cichy —
wykres wyglądał bez zarzutu. Kierunek bierzemy teraz z samych cuspów.

TOPOCENTRIC MA JEDNAK GRANICĘ DZIEDZINY — korekta tego, co pisałem wcześniej.
Cuspy są poprawne wszędzie (zgodne z wyrocznią co do zera), ale powyżej koła
podbiegunowego przestają DZIELIĆ OKRĄG: cusp VII (= I + 180°) wypada przed
cuspem VI i domy nachodzą na siebie. Przypisanie planety traci wtedy sens —
co potwierdza sama wyrocznia, której swe_house_pos przeczy tam własnym cuspom
(100% zgodności do 62°, 83,9% przy 66°, ok. 50% przy 72°; regiomontanus 100%
w tych samych punktach). Odmawiamy, z jawnym fallbackiem jak Placidus i Koch.

Próg jest WYPROWADZONY z warunku „dwanaście cuspów sumuje się do 360°", nie
dobrany pod wynik testu — i wypada na kole podbiegunowym (zmierzone: 100%
podziałów do 65°, 78% w pasie 66-67°). To inny rodzaj granicy niż u Placidusa
i Kocha: tam nie istnieją same cuspy, tu istnieją, tylko nie tworzą podziału.

Framework dostał pojęcie dziedziny WĘŻSZEJ niż wyroczni (NARROWER_THAN_ORACLE),
zamiast wyjątku „bo topocentric": skoro wyrocznia przeczy sama sobie, nie może
rozstrzygać, więc tam nie porównujemy — a nasze przypisanie jest w tym obszarze
sprawdzane testem samospójności z cuspami, bez swissepha.

UKŁAD STRONY — zmierzony na żywej stronie, nie na oko:
- tabela porównania przy 13 systemach miała 14 kolumn i 1863 px, a stała
  w rodzicu bez overflow-x, więc ROZPYCHAŁA CAŁY DOKUMENT: 1713 px przy oknie
  1280 px, poziomy pasek na body. Teraz ma własny kontener przewijany
  (dokument 1265 px, nie przewija się), a numer domu jest przyklejony do lewej,
  bo inaczej po przewinięciu nie wiadomo, który to wiersz.
- przypis „* nie działa za kołem podbiegunowym" siedział WEWNĄTRZ <label>
  selektora, łamał się na dwie linie i rozciągał wiersz siatki ze 66 do 108 px,
  rozjeżdżając go z sąsiednim polem. Wyjaśnienie stoi teraz raz, przy
  checkboxach z gwiazdkami; wiersz wrócił do 66 px.
- 13 checkboxów na flexie zawijało się w poszarpane wiersze — jest siatka
  o stałej szerokości kolumny (auto-fill, więc na wąskim ekranie kolumn mniej).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

services/logic/app/engine/houses.py

@@ -321,6 +321,22 @@ def _cusps_topocentric(ramc: float, eps: float, lat: float,
     Kusi, by liczyć to jak Regiomontanusa z podmienioną szerokością — daje wynik
     bliski, ale nie równy (kilka sekund łuku); wyrocznia rozstrzygnęła na rzecz
     konstrukcji „ascendent pod biegunem"."""
+    # Cuspy topocentrica są poprawne na CAŁEJ dziedzinie (zgodne z wyrocznią co do
+    # zera), ale powyżej koła podbiegunowego przestają DZIELIĆ OKRĄG: domy nachodzą
+    # na siebie, bo cusp VII (= I + 180°) wypada przed cuspem VI. Przypisanie planety
+    # do domu traci wtedy sens — co potwierdza sama wyrocznia, której swe_house_pos
+    # przeczy tam własnym cuspom (100% zgodności do 62°, 83,9% przy 66°, ok. 50%
+    # przy 72°). Odmawiamy, zamiast zwracać liczbę bez znaczenia.
+    #
+    # To INNY rodzaj granicy niż u Placidusa i Kocha: tam nie istnieją same cuspy,
+    # tu istnieją, tylko nie tworzą podziału. Próg jest wyprowadzony z warunku
+    # „dwanaście cuspów sumuje się do 360°", nie dobrany pod wynik testu — i wypada
+    # na kole podbiegunowym (zmierzone: 100% podziałów do 65°, 78% w pasie 66-67°).
+    if abs(lat) >= polar_circle(eps):
+        raise HouseSystemUndefined(
+            f"φ={lat:.4f}° powyżej koła podbiegunowego ({polar_circle(eps):.4f}° dla "
+            f"ε={eps:.4f}°): cuspy topocentryczne przestają dzielić okrąg, "
+            f"domy nachodzą na siebie")
     er, tan_lat = math.radians(eps), math.tan(math.radians(lat))
     epole = _ecliptic_pole(er)
     # Gdy MC górujące rozjeżdża się z matematycznym (za kołem podbiegunowym),
@@ -534,14 +550,38 @@ def cusps_detailed(ramc: float, eps: float, lat: float, system: str) -> CuspSet:
                        FALLBACK_SYSTEM, system, str(e))
 
 
+def _runs_forward(cusp_list: list[float]) -> bool:
+    """Czy domy biegną w stronę rosnących długości ekliptycznych.
+
+    Zwykle tak — ale NIE ZAWSZE. Przy dużych szerokościach systemy dzielące koła
+    wielkie (regiomontanus, campanus, topocentric) mają kolejność ODWRÓCONĄ:
+    przy φ = −84,3° cusp domu I wypada na 174,2°, a domu II na 165,3°. To nie
+    jest błąd — wyrocznia zwraca dokładnie te same wartości.
+
+    Rozstrzygamy sumą przeskoków „do przodu": dwanaście cuspów dzieli okrąg, więc
+    idąc we WŁAŚCIWĄ stronę zsumują się do 360°. Idąc pod prąd każdy przeskok
+    obchodzi koło dookoła i suma wychodzi 11 × 360° = 3960°."""
+    total = sum((cusp_list[(i + 1) % 12] - cusp_list[i]) % 360.0 for i in range(12))
+    return abs(total - 360.0) < abs(total - 3960.0)
+
+
 def assign_house(lon: float, cusp_list: list[float]) -> int:
-    """Numer domu (1..12), w którym leży dana długość ekliptyczna."""
+    """Numer domu (1..12), w którym leży dana długość ekliptyczna.
+
+    Kierunek liczenia bierzemy z samych cuspów. Zaszycie „zawsze do przodu"
+    dawało przy |φ| powyżej koła podbiegunowego złe domy dla regiomontanusa,
+    campanusa i topocentrica — mimo cuspów zgodnych z wyrocznią co do zera.
+    Błąd był CICHY: wykres wyglądał poprawnie, tylko planety siedziały gdzie
+    indziej. Sprawdzane wobec swe_house_pos (tests/oracle)."""
     lon = norm360(lon)
+    forward = _runs_forward(cusp_list)
     for i in range(12):
         start = cusp_list[i]
         end = cusp_list[(i + 1) % 12]
-        span = (end - start) % 360.0
-        offset = (lon - start) % 360.0
+        if forward:
+            span, offset = (end - start) % 360.0, (lon - start) % 360.0
+        else:
+            span, offset = (start - end) % 360.0, (start - lon) % 360.0
         if offset < span:
             return i + 1
     return 12