build(deps): add django-admin-rest-api + django-admin-mcp-api sibling packages (Phase 1 of #544) (#545)

* build(deps): add django-admin-rest-api ^0.1.0a0 (Phase 1 of #544)

The JSON REST API surface (every list / detail / create / update /
delete / action / history / autocomplete endpoint) lives in the sibling
package `django-admin-rest-api` on PyPI — same `ModelAdmin` source of
truth, same permissions, no new features. This repo's role becomes
the React super-layer on top of it.

Phase 1 only **adds** the dependency. No URL rewires, no deletions:
`poetry install` resolves cleanly, `import django_admin_rest_api`
succeeds, and the full test suite is **green (572 passed)** against
the unchanged local `django_admin_react/api/` implementation. The
package is just present — both stacks coexist.

Subsequent phases (per #544):
- Phase 2: swap `urls.py` to `include("django_admin_rest_api.urls")`.
- Phase 3: delete `django_admin_react/api/` + its tests.
- Phase 4: drop duplicated supporting files (audit / conf / apps).
- Phase 5: refresh docs to position this as the React super-layer.
- Phase 6: PyPI screenshot pack (#87).
- Phase 7: release hygiene.

Refs #544

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* build(deps): also add django-admin-mcp-api ^0.1.0a0 — ship MCP alongside React

The MCP sibling package (django-admin-mcp-api 0.1.0a0) is now on PyPI —
a wire-protocol-only MCP adapter over django-admin-rest-api that lets
agents reach the SAME ModelAdmin-driven REST surface, with no new
functionality, permissions, or validation. Add it next to
django-admin-rest-api so Phase 1's "land the dependency floor" step
ships BOTH siblings — a consumer's `pip install django-admin-react`
resolves the React SPA and the MCP API server together, driven by the
same source of truth.

No deletions or rewires in this PR — the local django_admin_react/api/
tree is still wired; the new deps just sit alongside. URL include +
INSTALLED_APPS guidance for the joint shipping lands in later phases.

- pyproject.toml: add `django-admin-mcp-api = "^0.1.0a0"`.
- poetry.lock: regenerated, both packages resolve cleanly.
- Both `import django_admin_rest_api` and `import django_admin_mcp_api`
  succeed against the locked versions.
- Full backend test suite: 572 passed (no behaviour change).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Martin Castro Laminrs <mcastro@laminr.ai>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: 3 people

poetry.lock

@@ -42,6 +42,25 @@ python = "^3.10"
 # Django 5.0 → 5.2 LTS → 6.x. Bump the upper bound when 7.0 ships and
 # we've verified the package still passes its test matrix on it.
 django = ">=5.0,<7.0"
+# The JSON REST API surface (every list / detail / create / update /
+# delete / action / history / autocomplete endpoint) lives in this
+# sibling package — same `ModelAdmin` source of truth, same permissions,
+# no new features. This repo's role is the React super-layer on top of
+# it (META #544). The package is plug-and-play: it is added to
+# `INSTALLED_APPS` by `django_admin_react.apps.DjangoAdminReactConfig`,
+# and its `urls` are included by `django_admin_react.urls`. Phase 1 of
+# the migration only **adds** the dependency; the local
+# `django_admin_react/api/` tree is removed in later phases.
+django-admin-rest-api = "^0.1.0a0"
+# `django-admin-mcp-api` (sibling published to PyPI as part of the same
+# three-repo split, #544): an MCP-protocol adapter over the REST API so
+# agents reach the SAME `ModelAdmin`-driven surface. Wire-protocol-only
+# layer — adds NO new functionality, permissions, or validation; reuses
+# the rest-api package transitively. Phase 1 just lands the dependency
+# alongside `django-admin-rest-api`; later phases ship the joint
+# `INSTALLED_APPS` + URL include guidance, so a consumer's `pip install
+# django-admin-react` gives them the React SPA AND the MCP API server.
+django-admin-mcp-api = "^0.1.0a0"
 
 [tool.poetry.group.dev.dependencies]
 # Dependabot #5: pytest's tmpdir handled symlinks unsafely