The login/token flow worked but progress never synced. Four fixes:

- _update reads /anime-list/{id} (path) instead of the collection route
  /anime-list?animeId=, which ignores the param and returns an array, so
  the single-entry { entry } was never seen.
- Set _onList from the read; SingleAbstract only flips it true after a
  successful sync, so listed anime previously showed as not-on-list.
- _sync uses POST /anime-list (an upsert) instead of PATCH. PATCH on a
  missing row returns 500, not 404, so first-time tracking failed.
- apiCall surfaces non-2xx as real errors with the status, so a 4xx
  body is no longer mistaken for a successful response.

Read the anime metadata response unwrapped (no { data } envelope).

Renames the user-visible text only: the provider title in settings,
shortName, list name, OAuth success page, and error messages.

Internal identifiers stay as-is (ANIMEPULSE sync-mode value, the
animepulseToken storage key, the AnimePulse/ folder and import aliases).
The animepulse-token postMessage type is a wire contract shared with the
web app's /auth/extension page, so renaming it here alone would break
token capture.

…nknown sync mode')

Brings MyAnimePulse to parity with the built-in trackers across the
points the initial integration didn't cover:

- httpPermissions.json: grant host access to myanimepulse.com (needed
  for the background xhr that does the actual list read/write).
- provider/templates.ts: shortName for the overview/UI label.
- utils/syncHandler.ts: getType() detects myanimepulse.com, syncItem()
  dispatches to the AnimePulse single, and rewatch-count cross-sync is
  enabled (anime-only, so dates stay excluded).
- pages/pageInterface.ts + chibiScript provider() union: allow page /
  chibi scripts to resolve MYANIMEPULSE as the active provider. (The
  generated ChibiGeneratorTypes.ts picks this up on build.)

… with other providers)

Flip datesSupport on now that the API stores start_date/finish_date (animepulse MALSync#219) and accepts rewatchCount on POST (MALSync#221). Implement the four date getters/setters as YYYY-MM-DD strings (the abstract's startFinishDate type), read them back in _update sliced from the API's ISO datetimes, and send startDate/finishDate/rewatchCount in the _sync POST. Also makes _getRating async to satisfy the abstract's Promise<string> contract.

Renames ANIMEPULSE_INTEGRATION.md -> MYANIMEPULSE_INTEGRATION.md and replaces the stale pre-build plan with accurate present-tense docs: real auth flow (/auth/extension token), POST upsert (not the planned PATCH), the actual integration points (templates/syncHandler/pageInterface/coreFunctions/oauth/httpPermissions, not the singleFactory/pulse-id plan), and the endpoints/status map as shipped.

Renames src/_provider/AnimePulse -> MyAnimePulse and updates all 7 path imports plus the class aliases (AnimePulseSingle/List, animePulseSearch -> MyAnimePulse*), matching the MyAnimePulse brand used everywhere else. Internal keys left intentionally: the animepulseToken setting and the webpack 'animepulse' page-url key are renaming-neutral (changing the setting key would invalidate stored tokens and force re-auth). tsc clean, webextension builds.

translateList fell through to PLAN_TO_WATCH for status.Rewatching (23) since MyAnimePulse's enum has no rewatching value, so starting a rewatch wrongly demoted a Completed entry to Plan-to-Watch. Map an in-progress rewatch to Watching; the rewatch count still increments on finish.

MyAnimePulse stores an in-progress rewatch as WATCHING + is_rewatching=true (animepulse MALSync#226). Map status.Rewatching to/from the flag: _setStatus records it, _getStatus returns Rewatching when set, _update reads it, _sync sends it. Replaces the lossy Rewatching->Watching collapse so the site can badge active rewatches; the count still bumps on finish.

SingleAbstract.increaseRewatchCount() is a no-op stub providers must override (MAL/AniList/Kitsu do). Ours didn't, so finishRewatchingMessage() flipped status back to Completed but never bumped rewatchCount. Override it to persist the +1.