[PBI] Deprecation of the legacy data layer

[cjlapao]

Description

Formally mark the legacy data layer as deprecated in the codebase, add runtime deprecation warnings where it is still reachable, and prepare a documented removal plan for a future release.

User Story

As a maintainer, I want the legacy data layer to be clearly marked as deprecated with a documented removal timeline, so that there is no ambiguity about its future, and contributors do not accidentally extend it.

Acceptance Criteria

• Code annotation: All public types, functions, and packages belonging to the legacy layer are annotated with a // Deprecated: GoDoc comment pointing to the replacement.
• Runtime warning: If the legacy layer is somehow reached at runtime (e.g. via a feature flag or fallback), a deprecation warning is logged at the warn level on startup.
• No new callers: A linter rule or CI check prevents new code from importing the deprecated package.
• Removal issue created: A GitHub issue is created and linked, targeting the next major version, describing the steps to fully remove the legacy layer.
• Changelog entry: The deprecation is documented in CHANGELOG.md with the version it takes effect and the planned removal version.

Definition of Done

• Code implemented following best practices.
• Unit tests written and passing.
• Code reviewed and approved.
• Merged into the main branch.
• Documentation updated (if applicable).
• Deployed to staging/production environment.

Assumptions and Constraints

No response

Dependencies

• Assumption: There are no external consumers of the legacy data layer's public API (it is internal to the service).
• Constraint: The legacy layer must remain functional until the removal release to avoid breaking users who are still on older builds.

Additional Notes

No response