chore(api): drop the dead dev Dockerfile and read the app version from metadata

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.

[nadeem4]

Two small, independent cleanups in the API package.

1. Delete the orphaned packages/api/Dockerfile.dev

The file was tracked but dead. 12 of its 17 COPY paths pointed at the
packages/core, packages/adapter-sqlalchemy and
packages/adapters/{mssql,mysql,postgres,sqlite} layout that was removed in the
distribution collapse. Only 5 paths still resolve, so the image could not build
at all — the first COPY ./packages/core/pyproject.toml fails outright.

It has no live references anywhere in the repo: no workflow, compose file,
doc, or task runner mentions it. Every Dockerfile reference in the tree points
at packages/api/Dockerfile.

packages/api/Dockerfile — the real one used by the GHCR build in
.github/workflows/publish_pypi.yaml — is untouched, and all three of its
COPY paths resolve against the current layout.

2. Read the FastAPI app version from the distribution metadata

main.py hardcoded version="0.1.0" in the FastAPI(...) constructor, and
nothing bumped it. It happened to agree with packages/api/pyproject.toml
today, but release-please only bumps the pyproject.toml marker — so the very
next release (0.1.1) would have left the OpenAPI spec advertising 0.1.0, a
version the package no longer is. That gap would widen with every subsequent
release, and anything relying on the served spec to identify the API build
would be quietly wrong.

The version is now read at runtime via
importlib.metadata.version("nl2sql-api"), so it tracks pyproject.toml
automatically. Deliberately no# x-release-please-version marker is added
here: reading the installed metadata is the point, and a second bump target
would just be one more thing to drift.

PackageNotFoundError falls back to "0.0.0" so the app still imports from a
source tree where the distribution is not installed. 0.0.0 is a valid PEP 440
version that sorts below every real release, matching the convention the
release manifest is already seeded with, and it cannot be mistaken for a
published build.

Tests

Added to the existing packages/api/tests/test_app.py:

• test_app_version_matches_installed_distribution asserts app.version
  equals importlib.metadata.version("nl2sql-api") rather than a hardcoded
  literal, so the test cannot itself go stale.
• test_app_version_falls_back_when_distribution_is_missing monkeypatches the
  lookup to raise PackageNotFoundError and confirms the fallback path returns
  a version instead of raising.

Both fallback and normal branches were confirmed to be genuinely exercised
(0.0.0 and 0.1.0 respectively).

Unit: 261 passed, 1 skipped, 47 deselected (259 baseline + the 2 new tests).
Key-free integration: 28 passed. Both suites run twice under pytest-randomly.

No changes to CHANGELOG.md, any pyproject.toml version, or
.release-please-manifest.json.