Feat: rename oversized containers from their edit form

[Rom1-B]

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

• It fixes !45901
• When a container's computed table name exceeds MySQL's 64-character limit, the plugin now disables it instead of crashing, and shows a rename form directly on the container's edit page.
• Submitting a shorter name renames the container and reactivates it; if a table with matching data already exists under that name (e.g. after a version migration), its data is preserved instead of being replaced by an empty table.
• plugins:fields:check_database now also reports container/item type pairs with no matching table, and tables with no matching container/item type pair.

Screenshots (if appropriate):

[stonebuzz]

renameOversizedContainer has no server-side guard that the target container is actually disabled or oversized.

Suggested change

	if ((int) $container->fields['is_active'] !== 0) {
	Session::AddMessageAfterRedirect(__('Container is already active.', 'fields'), false, ERROR);
	return false;
	}

[Rom1-B]

Good catch, but a strict is_active === 0 check would break the orphan-recovery path (an active container whose table got corrupted by an old migration bug, see testRenameOversizedContainerRecoversDataFromOrphanTable). Added a guard instead that requires the container's current name to actually produce an oversized table, same condition already used to show the "Rename and reactivate" button.