Blocking books in staging for `Language` metadata changes is painful

We very regularly have books blocked in staging due to Language metadata changes.

These changes are very expected because it is just related to the amount of things in the ZIM changing, which in turns causes a reordering of the list of languages, and/or a new language appearing.

See e.g. https://cms.openzim.org/book/b4484eb2-7b7f-9bc7-f52c-4ff3edfb71d5/issues

or

https://cms.openzim.org/book/73b60d1c-1b5c-5c3d-4d36-71358daaa311/issues

This is painful because:

• it requires human intervention for something which is hard to confirm is normal
• it blocks many books in staging (ATM mostly all new TED books have been blocked in staging)

I don't know yet if we should:

1. just make the UI better by more clearly stating what changed in the list (typically show a diff with one language per line so that it is easier to see at a glance what changed)
2. consider we should start accepting that some metadata are not manually validated anymore and are directly pushed to production (book can go straight to prod when this metadata is updated and the title metadata is automatically updated

I hesitate between both alternatives because option 1 implies we still have human intervention needed but option 2 seems a bit risky (we want a human to validate changes).

@Popolechien @kelson42 WDYT?

Start with the two linked CMS book issue pages and compare how Language metadata changes are shown and handled in staging. Resolve whether the goal is a clearer diff, automatic promotion, or both; done means the chosen workflow reduces unnecessary blocking while preserving the intended human validation.