TAN-8139: Source the public API project and folder descriptions from the Content Builder

[EdwinKato]

Part of TAN-8139. Lands before #14434 so that PR no longer has to remove anything from the public API.

The legacy WYSIWYG description_multiloc is on its way out, but three public API fields read it: description_html on /api/v1/projects and /api/v2/projects, and description_multiloc / description on /api/v2/project_folders. Dropping the keys would break integrations — our own Power BI template names them explicitly in its M query, so a missing key fails the whole projects table on the next refresh, not just one column.

So the fields stay, rebuilt from the layout that superseded the column: project_page for a project, project_folder_description for a folder. ContentBuilder::Craftjs::VisibleTextualMultilocs already did the extraction for the admin API; the new service just picks the right layout and hands back a multiloc.

Only text widgets carry over. For a project migrated and not edited since, the original HTML sits in one bridge widget and comes back intact — the v1 acceptance spec's existing exact-HTML assertion passes untouched. For a project rebuilt in the page builder, it is a text-only rendering, which is all a plain HTML field can express anyway.

List endpoints preload content_builder_layouts and the service scans the loaded association, so there is no N+1. Each record still costs a craftjs walk; worth watching if these endpoints turn out to be busy.

Changelog

Technical

• Project and folder descriptions in the public API are now built from their page
  builder content instead of the old description field, so they keep working once
  that field is removed.

[notion-workspace]

Clean up WYSIWYG descriptions that are no longer used

[notion-workspace]

Clean up WYSIWYG descriptions that are no longer used

[cl-dev-bot]

	Messages
📖	Changelog provided 🎉
📖	Notion issue: TAN-8139
📖	Run the e2e tests
📖	Check translation progress

Generated by 🚫 dangerJS against 88d6469