Standardize key naming

Define _key for surrogate, smart and hashes keys.
Define _id for business keys.

Using _sk for surrogate leads to using _key for smart keys, for example. Which may introduce clutter.
_key unifies the three types which have the same functionality anyway.

This is the types of surrogate key implementations:

- Sequential Integer Key — Auto-incrementing numeric surrogate key (1, 2, 3...). Compact, fast joins, classic Kimball approach.
- Hash-Based Key — Deterministic hash generated from one or more fields (e.g. md5(customer_id)). Common in dbt/cloud warehouses for stable incremental builds.
- UUID/GUID Key — Globally unique generated identifier (550e8400-e29b...). Useful in distributed systems, but larger and slower for joins.
- Smart Key — Key containing embedded business meaning (e.g. 20260526 for dates). Human-readable but less flexible; usually avoided except for Date dimensions.

No matter the implementation we should stick to '_key'.