<h3 id="summary-problem-motivation">Problem/Motivation</h3> When ai_translate is used together with layout_builder_at for asymmetric Layout Builder translations, translated inline blocks are cloned correctly, but inline_block_usage rows are not created for the cloned translated blocks. This leaves the translated inline blocks in an incomplete state and later causes access dependency failures, for example when opening Media Library on a media field inside the translated inline block. <h4 id="summary-steps-reproduce">Steps to reproduce</h4> 1. Enable `ai_translate` / `layout_builder_at` / Layout Builder on a translatable content type 2. Create a node using Layout Builder. 3. Add a non-reusable inline block to the layout. 4. Save the node. 5. Confirm the original inline block has a row in inline_block_usage. 6. Create a translation manually through the normal translation UI. 7. Confirm the translated cloned inline block also gets a row in inline_block_usage. 8. Create another translation through the AI translation flow. 9. Inspect the cloned translated inline block created by AI translation. 10. Observe that the cloned block exists and is referenced by the translated layout, but has no corresponding row in inline_block_usage. <h3 id="summary-proposed-resolution">Proposed resolution</h3> In the asymmetric Layout Builder translation flow inside ai_translate, after cloning and saving the translated inline block, register usage for the cloned block against the translated host entity. The AI translation path should mirror the relevant behavior already present in the normal layout_builder_at manual translation flow. <h3 id="summary-remaining-tasks">Remaining tasks</h3> None. <h3 id="summary-ui-changes">User interface changes</h3> None. <h3 id="summary-api-changes">API changes</h3> None. <h3 id="summary-data-model-changes">Data model changes</h3> None.