Add optional strict validation for render-only page models

[gregjotau]

Classification

Needs discussion before implementation. These restrictions could make rendering deterministic and prevent performance regressions, but some are policy choices rather than requirements of the renderer.

Goal

Allow applications to opt dedicated page-model packages or types into a stricter closed-world contract.

Candidate checks:

• fail on page-model properties unused by the fully expanded template graph
• reject Any, Object, raw generic types, and dynamic map-shaped data
• reject JPA entity types and Hibernate persistent collections
• reject mutable properties
• require typed, materialized collections for iteration
• warn or fail on unordered collection iteration where stable output is expected
• reject types whose nullability cannot be established safely

Why

A page model should ideally be immutable data already prepared for rendering. Passing entities or lazy collections can cause database access and N+1 queries during rendering. Unused page properties can reveal stale calculations, unnecessary queries, or incomplete template changes made by agents.

Design questions

1. Is strictness enabled by package, naming convention, annotation, or Gradle configuration?
2. Which checks are errors versus warnings?
3. How can legitimate shared DTOs or infrastructure fields opt out explicitly?
4. Should unused-property checking include properties consumed only by backend code, or apply solely to dedicated *Page types?
5. Which collection interfaces are accepted while preserving deterministic, I/O-free rendering?
6. Should JPA detection be annotation-based without introducing a JPA dependency?

Constraints

• Keep the default model rules small unless strict mode is explicitly enabled.
• Analyze properties after fragment/layout expansion.
• Do not perform runtime checks or load JPA/Hibernate classes reflectively.

[gregjotau]

@giap This needs discussion because forbidding entities and dynamic shapes is attractive, but unused-property and collection rules could be too opinionated unless strict mode and opt-outs are designed carefully.

[lehoanggiap]

IMO, I think we should start with low-risk checks, such as:

• Reporting unused properties as warnings.
• Reporting mutable properties as warnings or errors.
• Rejecting obvious Any or raw Object types.
• Requiring typed iterable values for th:each.

For more advanced checks, such as JPA-specific validation, I don't think we should support them. They would introduce tight coupling between Thim and JPA. For example, if a project stops using JPA or changes how entities are initialized, Thim would also need to adapt to those implementation details. I think it's better to keep Thim framework-agnostic and avoid coupling it to backend persistence technologies.

[lehoanggiap]

3582855