py-v1.16.0 - SQLAlchemy support: scan, ER diagrams and N+1 for SQLAlchemy models

Changed

• django-orm-lens is now orm-lens, and reads SQLAlchemy models.
  The package is orm-lens on PyPI, with the commands orm-lens and
  orm-lens-mcp and the module orm_lens. Nothing written against the old
  name breaks: pip install django-orm-lens (and [mcp]) installs the
  matching orm-lens and keeps the django-orm-lens / django-orm-lens-mcp
  commands and import django_orm_lens, and upgrading an existing install
  keeps both command names. The MCP server reads ORM_LENS_ROOT and
  ORM_LENS_ALLOWED_ROOTS, then the old DJANGO_ORM_LENS_* names. The
  repository moved to github.com/FROWNINGdev/orm-lens (the old URLs
  redirect), the docs to frowningdev.github.io/orm-lens, the MCP Registry
  entry to io.github.FROWNINGdev/orm-lens, and the image to
  ghcr.io/frowningdev/orm-lens (ghcr.io/frowningdev/django-orm-lens keeps
  getting the same builds). Kept on purpose: the pre-commit hook ids, the
  SARIF tool name (code scanning keys open alerts on it) and the blast-radius
  PR-comment marker. The GitHub Action still accepts a pre-1.16 version.

Added

• SQLAlchemy models: scan, ER diagrams and N+1 (preview).
  scan, list, describe, hover, er and nplusone, and the matching
  MCP tools, now read SQLAlchemy models: 2.0 DeclarativeBase / Mapped[],
  1.x declarative_base() / Column, Flask-SQLAlchemy db.Model and
  SQLModel table=True classes. Static as always: ast, no import, no
  database. Bases and mixins are followed across files, table names come
  from __tablename__ or the base's naming rule, foreign keys become ER
  edges, and relationship() attributes are listed with their loader.
  nplusone flags a loop over query results that reads a lazy relationship
  without selectinload / joinedload in the query's options, and suggests
  the option. The Django analyses (drift, blast radius, cascade, signals)
  stay Django-only. Checked on Superset, Airflow, Prefect, Polar, Dispatch,
  Mealie, CTFd, Redash and the FastAPI template: 12 N+1 findings, all real.
  See docs/rules/sqlalchemy.md.

Fixed

• SQLAlchemy and Flask classes no longer pass for Django models. A
  models.py with class User(db.Model) or Flask-AppBuilder's Model
  matched the parser's Model heuristic, so a Flask project showed up as a
  Django one: 65 phantom models in Superset, 138 in Polar, 69 in Dispatch.
  Files that are SQLAlchemy code and never import Django are now left to
  the SQLAlchemy reader. The Django projects in the census are unchanged.