[FEATURE] Style Properties Storage and API System

Problem

Problem
dotCMS has no mechanism to store or manage style configuration data per contentlet instance in a page. The system needs both database foundation and write operations to enable the Style Editor, but the complex multi_tree composite primary key makes this significantly more challenging than typical content operations.

Goal

Goal
Implement complete backend infrastructure, including database schema, write API endpoints, validation, and read operations that handle the complex multi_tree primary key structure and provide reliable style property management.

Personas
Content teams: Need reliable saving and loading of style changes made in Style Editor
Developer teams: Need robust API that integrates with existing page editing workflows
System administrators: Need smooth upgrade path and production-ready performance

Target Personas

• Developer teams
• Content teams
• DevOps teams
• System administrators (dotCMS)

Demo Expectations

Demo Expectations
User REST API to successfully save configuration changes to database
API handles complex multi_tree identifiers (page, container, relation, personalization, variant)
Validation prevents invalid style values based on registered schemas
Database migration successfully adds style_properties JSONB column with no performance impact
Error handling provides clear feedback for failed operations

Acceptance Criteria

No response

User Stories

No response

Links

No response

No files, tests, or entry points are named. Start by locating the existing contentlet and multi_tree handling, then map where database migrations, write and read APIs, and validation belong; done means the listed demo expectations and acceptance behavior are covered.