Migrating from HikerAPI

- GET https://api.hikerapi.com/v2/user/followers?user_id=25025320&page_id=ABC
- x-access-key: <key>
+ GET https://api.herascrape.com/users/25025320/followers?cursor=ABC
+ x-api-key: <key>

- GET https://api.hikerapi.com/v2/media/info/by/code?code=B4XpqViUFUI&safe_int=true
+ GET https://api.herascrape.com/posts/B4XpqViUFUI

- GET https://api.hikerapi.com/v2/user/by/username?username=instagram
- GET https://api.hikerapi.com/v2/user/stories/by/username?username=instagram
+ GET https://api.herascrape.com/users/username/instagram   # returns pk, cache it
+ GET https://api.herascrape.com/users/25025320/stories

You are migrating this codebase from HikerAPI (api.hikerapi.com) to
herascrape (api.herascrape.com).

First, read these — they are the source of truth, and this prompt alone is not
enough to do the migration correctly:

- https://herascrape.com/docs/llms-full.txt
  The complete herascrape documentation as one plain-text file: every endpoint,
  the pagination and error contracts, and the full HikerAPI translation tables.
- https://herascrape.com/docs/guides/hikerapi-migration
  The migration guide on its own, if you want just the tables.
- https://api.herascrape.com/openapi.json
  The OpenAPI (Swagger) schema, emitted by the running service. Authoritative
  for paths and parameters; use the "What comes back" examples in the docs for
  response field names.

Then, across the whole repo:

1. Replace the base URL https://api.hikerapi.com with
   https://api.herascrape.com.
2. Rename the auth header `x-access-key` to `x-api-key`. Keep the value in
   its existing environment variable.
3. Rewrite every request path using the "Endpoint translation" tables. Many
   HikerAPI paths collapse onto one of ours — pick the matching row.
4. Users are addressed by numeric id (/users/{id}). The only username path is
   GET /users/username/{username}, which returns the profile including `pk`.
   Where the code called a by-username sub-resource (stories, highlights,
   followers), resolve the username once, cache the id, then call the
   id-based endpoint. Flag any place where caching is not straightforward.
5. Posts: replace by-id, by-code and by-url calls with GET /posts/{id}, which
   accepts either the media pk or the shortcode. Extract the shortcode from
   any instagram.com/p/<code>/ URL.
6. Replace all pagination parameters (page_id, next_page_id, max_id,
   next_max_id, min_id, end_cursor, page_token, reels_max_id,
   profile_grid_items_cursor, repost_next_max_id) with a single `cursor`.
   Read the next token from `next_cursor` and loop while `has_more` is true.
   Two exceptions: /posts/{id}/comments pages on `min_id` (branch on
   `has_more`), and /users/{id}/posts pages on `cursor` taken from
   `feed.profile_grid_items_cursor`.
7. Delete these parameters: safe_int, flat, force, amount, rank_token,
   expand_suggestion, can_support_threading.
8. List responses are wrapped in {items, next_cursor, has_more}. Where the
   old code read a bare array, read `items`. Object fields are otherwise
   unchanged — both APIs return Instagram's JSON.
9. Respect the rate limit: 10 requests/second per key. If the code fans out
   concurrently, cap it.
10. Do NOT invent endpoints. If a call maps to something in the "What we do
    not have" section of the migration guide, leave it in place and mark it
    with a TODO naming the limitation. Do the same for any field you cannot
    confidently map. Never guess a path that is not in the translation tables.

Produce a summary of every call site changed, plus the list of TODOs.