chore(engine): migrate to enforce phase + centralized constants

What does this MR do and why?

This MR consolidates and cleans up how the query engine tracks redaction-related metadata. This MR also centralizes some constants in preparation for broader ontology refactors and removing hardcoding more broadly.

The main codepath that changed is that get_id() and get_type() on QueryResultRow no longer accept a raw &str alias. They now take a &RedactionNode. The column name strings (_gkg_u_id, _gkg_u_type, etc.) were computed on every call by formatting the alias. Now they're precomputed once when the node is inserted into ResultContext, and stored directly on the RedactionNode struct.

The knock-on effect is visible in tests — you now resolve the node first (result.ctx().get("u")) and then use it. Slightly more verbose, but the function signatures actually tell you what they need now rather than silently computing a string from a raw alias.

A few structural changes followed from this:

• result_context.rs is deleted. ResultContext and RedactionNode moved into enforce.rs, which was also renamed from return.rs. The two files were always tightly coupled — enforce.rs was the only real consumer of ResultContext — so putting them together makes more sense.
• constants.rs is new. It centralizes the _gkg_ column name constants using const_format to build them from prefix components. Previously these were scattered across result_context.rs, security.rs, and lower.rs.
• QueryResult used to store node_aliases: Vec<String>. It now stores the full ResultContext. The node_aliases() method still exists but computes on demand, and a new ctx() accessor exposes the context directly.

Misc Changes:

• Bumped query-engine crate toedition 2024, which unlocks let-chain syntax (if let X = ... && let Y = ...). A few nested if let blocks got flattened using it.

Related Issues

Testing

All existing tests pass. The redaction_integration.rs test suite had to be modified to account for these new changes, but a script was written to perform said migration, and the complexity of the changes are low e.g adding a new variable per entity reference.

Performance Analysis

• This merge request does not introduce any performance regression. If a performance regression is expected, explain why.