feat(db): add release_level alongside release_status (BDMS-1382) - #1052

Why

This PR addresses the following problem / context:

• ReleaseMixin gives every record one release_status column that's being asked two unrelated questions at once: who may see it, and how far along it is in review. Per docs/release-level-and-data-maturity-vocabulary.md, this is step one of splitting that into two independent fields: adding release_level alongside the existing column.

How

Implementation summary: the following was changed / added / removed:

• Added a release_level lexicon category (pending/private/public) to core/lexicon.json, tagging the existing public/private terms and adding the new pending term. Added ReleaseLevel to core/enums.py.
• Added release_level to db/base.py's ReleaseMixin, defaulting new rows to pending.
• Added migration 73d27e78571a: adds release_level to all 35 ReleaseMixin tables and backfills it by exact value name only (public→public, private→private, draft/provisional→pending) -- raises rather than guessing if any other value shows up, since published/final/archived are expected to have zero rows anywhere.
• Also adds release_level to the _version shadow table of the 7 __versioned__ (sqlalchemy_continuum) tables among those 35, which must mirror the live table's columns or every write to them fails.
• release_status is not dropped in this PR -- kept for now, consumers migrated and the column dropped in later follow-ups.

Author Checklist

• Changes are limited to the intended scope.
• [N/A] Tests were added or updated where appropriate.
• Relevant tests and lint checks pass.
• No secrets, credentials, or sensitive data were publicly exposed.
• [N/A] Documentation was updated where necessary.

Reviewer Checklist

• Confirm draft/provisional→pending is the right backfill, and that raising on any other value (rather than defaulting it) is the right call.
• Confirm provisional→pending for transducer_observation/transducer_observation_block specifically -- this is still an assumption pending sign-off from whoever owns the hydrograph correction workflow, not a final decision.
• Confirm keeping release_status in place for now (two-step rollout) rather than dropping it in this same PR.

Notes

Any special considerations, known limitations, risks, workarounds, or follow-up work to note?

• This PR only adds release_level and backfills it -- updating the ~38 consumer files, the two materialized chemistry views, and dropping release_status are separate follow-up steps, not part of this PR.

• Verified: migration applies and reverts cleanly on a fresh local database; full test suite passes (1299 passed, 0 failures, excluding modules with a pre-existing unrelated missing-dependency issue in this environment).

• Two BDD scenarios in tests/features/ogc-cleanup-sprint1.feature fail against this branch: "Sprint 1 migration restricts all ogc_* views to public records" and "The 4 already-consistent layers are unaffected by the migration."

• Root cause: these scenarios deliberately rewind the real database schema to an old revision (PRE_A1_REVISION, well before this change) to test an old migration in isolation, then seed test data using the current SQLAlchemy ORM model classes. Since release_level is now a mapped column on ReleaseMixin, every model using it (Group, Location, etc.) always includes release_level in its generated INSERT statement -- regardless of whether it's set, and regardless of any default (client-side, server-side, or none at all; all three were tried and all fail the same way). Against the rewound schema, that column doesn't exist yet, so the insert fails with column "release_level" of relation "group" does not exist.

• I think this needs a fix on the test side (e.g., _seed_all in tests/features/steps/ogc-cleanup-sprint1.py seeding via raw SQL instead of the ORM for these two scenarios specifically) -- not resolved in this PR. @ksmuczynski @jirhiker any thoughts on this ?