Migrate from DivineAPI

You are migrating a codebase from the DivineAPI astrology API to the AstroAsk astrology API. Apply these rules exactly and convert every DivineAPI call you find. Output complete converted files — do not truncate or summarize.

AUTH: DivineAPI sends a Bearer token AND `api_key` in the form body. AstroAsk uses ONLY a header: `Authorization: Bearer <key>` (or `X-API-Key: <key>`). Remove api_key from every request body.

BASE URL: DivineAPI uses https://astroapi-N.divineapi.com per endpoint. AstroAsk uses one base: https://api.astroask.app/v1

REQUEST FORMAT: DivineAPI = multipart/form-data. AstroAsk = application/json.
Map birth-data fields:
- day, month, year, hour, min, sec  ->  date: "YYYY-MM-DDTHH:MM:SS" (LOCAL time at the birth place; do NOT convert to UTC)
- lat -> lat (number)
- lon -> lng (number; note the rename)
- tzone (numeric offset like 5.5) -> timezone (IANA string like "Asia/Kolkata"). If you only have the offset, omit timezone; AstroAsk resolves it from lat/lng.
- full_name, gender, place -> not sent; keep them in the app's own state
- lan -> lang
Two-person endpoints: p1_*/p2_* prefixed fields -> { "person1": {date,lat,lng,timezone}, "person2": {...} }

ENDPOINT MAP (DivineAPI -> AstroAsk):
- /indian-api/v2/planetary-positions -> POST /v1/planets
- /indian-api/v3/basic-astro-details -> POST /v1/ascendant, /v1/moon-sign, /v1/sun-sign, /v1/nakshatra (or one POST /v1/batch)
- /indian-api/v1/horoscope-chart/D1 -> POST /v1/chart/north-indian (image) or POST /v1/kundali (JSON)
- /indian-api/v1/vimshottari-dasha -> POST /v1/dasha/vimshottari
- /indian-api/v2/find-panchang -> GET /v1/panchanga?date=&lat=&lng=
- /indian-api/v2/ashtakoot-milan -> POST /v1/compatibility/ashtakoot
- /indian-api/v2/manglik-dosha -> POST /v1/dosha/manglik
- /indian-api/v1/kaal-sarpa-yoga -> POST /v1/dosha/kaal-sarp
- /indian-api/v2/shadbala -> POST /v1/shadbala
- /indian-api/v2/yogas -> POST /v1/yogas
- /indian-api/v3/sadhe-sati -> POST /v1/sade-sati
- numerology endpoints -> POST /v1/numerology/life-path | core-numbers | destiny | soul-urge | personality | personal-year | business-name
- western endpoints -> POST /v1/western/natal | aspects | transits | synastry | progressions | solar-return | composite | davison | arabic-lots | midpoints

RESPONSE ENVELOPE: DivineAPI {"success":1,"data":...}. AstroAsk {"success":true,"data":...}; on error {"success":false,"error":"CODE","message":"..."}. Check the boolean.

RESPONSE FIELDS — planets (data.planets[]):
- name -> planet
- full_degree (STRING "38.7863050") -> longitude (NUMBER). Remove parseFloat.
- longitude (DMS string "8:47:10") -> degreeInSign (decimal number)
- sign (name) -> signName
- sign_no (1-based, Aries=1) -> sign (0-BASED, Aries=0). Add 1 if the UI expects 1-based.
- speed (string) -> speed (number)
- is_retro (STRING "false") -> isRetrograde (BOOLEAN). Remove any === "true" comparisons.
- is_combusted (string) -> isCombust (boolean)
- nakshatra -> nakshatra, BUT some spellings differ and DivineAPI is inconsistent with itself. Normalize DivineAPI->AstroAsk: Aswini->Ashwini, Moola->Mula, Shravan->Shravana, Dhanishtha->Dhanishta, Satabhisha->Shatabhisha, "Purva Ashada"->"Purva Ashadha", "Uttara Ashada"->"Uttara Ashadha", "Poorva Bhadrapada"->"Purva Bhadrapada". AstroAsk KEEPS the space in two-word names ("Purva Phalguni", "Uttara Bhadrapada"). Never compare nakshatra names across the two APIs with ===; compare nakshatraPada + degree, or normalize first.
- nakshatra_pada -> nakshatraPada; nakshatra_lord -> nakshatraLord; sub_lord -> subLord
- awastha (one word) -> avastha.baladi (+ avastha.jagradadi, avastha.strengthModifier)
- house -> house
- NEW on AstroAsk: subSubLord, isVargottama, navamsaSign, navamsaSignName, dignity, houseClassifications[], eclipticLatitude
- rashi_lord, lord_of, type(benefic/malefic), image: NOT on the planet object. Derive rashi_lord/type from a client-side lookup, get lordship from POST /v1/houses/vedic.

RESPONSE FIELDS — vimshottari dasha:
- data.maha_dasha.<PlanetName> (object keyed by planet) -> data.periods[] (ORDERED ARRAY, each has .planet). Iterate the array; do not look up by key.
- start_date/end_date (date-only) -> start/end (exact ISO timestamps)
- antar_dasha.<Planet> -> antardashas[] (array)
- "--" sentinel for past periods -> DOES NOT EXIST; every period has real timestamps. Delete any "--" guards.
- NEW: data.current {mahadasha, antardasha, start, end}, .durationYears, .lordStrength

RESPONSE FIELDS — ashtakoot:
- data.ashtakoot_milan.<koota> (object) -> data.koots[] (array with .name)
- points_obtained -> score; max_ponits -> maxScore; area_of_life -> areaOfLife; p1/p2 unchanged
- description (mail-merged prose) -> NOT returned; render your own from score/p1/p2 or call POST /v1/compatibility/summary
- NEW: data.totalScore, data.rating, data.doshas[], data.isCompatible

RESPONSE FIELDS — manglik:
- manglik_dosha "Yes"/"No" -> isManglik boolean; strength -> severity; percentage same
- NEW: references[] {reference: fromLagna|fromMoon|fromVenus, house, triggers}, cancellations[], isCancelled
- remedies[]/comment[] -> not returned

KNOWN DIFFERENCES (do not "fix" these): longitudes differ in the 3rd decimal (rounding); dasha boundaries are exact instants not dates; manglik is checked from Lagna, Moon AND Venus so a chart can be Manglik here and "No" on DivineAPI — that's a methodology difference, surfaced in references[]; Rahu/Ketu use Mean Node.

NOT AVAILABLE on AstroAsk: prose predictions/remedies, gemstone/rudraksha, PDF reports, Jaimini, Lal Kitab, Varshphal, KP cuspal significators, festival calendars, South-Indian chart style. If the code depends on one of these, keep that single DivineAPI call and migrate everything else; say so explicitly in your output.

AFTER CONVERTING: add a small script that calls both APIs for the same birth data and asserts sign, nakshatra, nakshatraPada and house match for every planet, and logs the longitude delta. Then list every file you changed.

Here is the code to migrate: