[IDEA] Deprecate document.page.history and use base_revision

[diggy128]

Is your feature request related to a problem?

• Document_page_history handles only changes in document content.
• In ISO (and most other certification schemes, I guess) changes in the context of the document (aka scope, use, applicability, responsibility) should also create a new version.
• Document history has been problematic working ON / OFF between Odoo versions

Describe the solution you'd like
Remove document.page.history completely and replace, inheriting from base_revision.
Using base_revision as the foundation for document revisions in the document_page module would simplify the architecture considerably while also making revision tracking more complete and consistent.

Today, document.page.history duplicates part of the data model and requires explicit logic to decide which fields are copied into history records. This creates several limitations:

• only selected fields are revisioned (content)
• schema changes must be mirrored manually
• custom modules adding fields are not automatically revision-aware
• history synchronization logic becomes harder to maintain
• revision consistency depends on custom implementation details

By refactoring document_page to inherit from base_revision, revisions would become model-native instead of relying on a parallel history model.

Key advantages of this approach:

• Automatic revisioning of all fields
  Any stored field added by OCA or third-party modules automatically becomes part of the revision system without additional code.
• Elimination of duplicated models
  Removing document.page.history reduces maintenance burden and avoids keeping two partially synchronized representations of the same document.
• Better extensibility for OCA ecosystem modules
  Modules extending document.page would gain revision support automatically, including custom metadata, categorization, workflow fields, attachments, references, etc.
• Consistent behavior with other OCA modules
  base_revision already provides a standardized revision workflow used across the OCA, improving predictability and reducing custom code.
• Reduced upgrade complexity
  Future field additions or refactors would not require updating history-copying logic or migration scripts for duplicated fields.
• Improved auditability
  Since revisions are based on the actual business record structure, the revision history becomes more complete and reliable, thus you get a better point-in-time view of the documents.
• Cleaner ORM integration
  Access rights, computed fields, tracking behavior, and inheritance patterns remain centered on a single model architecture instead of a shadow history model.
• Easier maintenance long-term
  Less custom revision logic means fewer edge cases and lower risk of history inconsistencies (issues such as [18.0][FIX] document_page: Don't change last history name and summary… #565).

This refactoring would effectively shift the module from a “manual snapshot/history table” approach to a generic ORM-level revision mechanism, making the revision system both more powerful and easier to maintain.

Furthermore any logic that needs to be used for documents (such as summary of changes) can be added to base_revision so all modules that inherit from it can use it if it makes sense for them.

Describe alternatives you've considered
Duplicate all fields of document.page to document.page history and keep track of changes.

Additional context
This is just a use case investigation and I haven't reached deep in implementation details.

What do you think @etobella @pedrobaeza @victoralmau