Replace hardcoded timestamp sentinels with MAX/MIN_TIMESTAMP constexprs

Introduce named sentinel constants for the bitemporal timestamp range and use them everywhere the literals appear today:

• Move MAX_TIMESTAMP ("9999-12-31 23:59:59") from ores.database/repository/helpers.hpp to db_types.hpp, next to db_timestamp itself. helpers.hpp already includes db_types.hpp so all existing users keep working.
• Add a MIN_TIMESTAMP counterpart for the start-of-time sentinel.
• Switch the codegen template (cpp_domain_type_entity.hpp.mustache) and all ~137 entity headers from the hardcoded literal to db_timestamp valid_from = MAX_TIMESTAMP;.
• While in the template, also fix the pre-unification drift: lines 56-57 still emit the optional<sqlgen::Timestamp> variant that the timestamp unification story eliminated.

The literal "9999-12-31 23:59:59" is hardcoded in 137 entity headers, the codegen template, and CurrencyDetailDialog.hpp — yet MAX_TIMESTAMP already exists as a constexpr in helpers.hpp. Entities cannot include helpers.hpp cheaply (it drags in boost exception diagnostics, sqlgen/postgres.hpp and logging), which is why the duplication arose. A magic string repeated 280+ times is a single-point-of-change hazard; the constant belongs in the same lightweight header as the type it parameterises.

Surfaced during review of PR #1036 (timestamp unification mop-up), where badge_mapping_entity copied the hardcoded-literal idiom from its 136 siblings.

• projects/ores.database/include/ores.database/repository/helpers.hpp:40 — existing MAX_TIMESTAMP.
• projects/ores.codegen/library/templates/cpp_domain_type_entity.hpp.mustache:56-57,98-99 — template hardcoding (and optional<> drift).
• projects/ores.qt/refdata/include/ores.qt/CurrencyDetailDialog.hpp:181 — duplicate local constant.
• PR #1036 review thread on badge_mapping_entity.hpp.

• Story: Unify entity timestamp handling — the story this fell out of.