feat(datasets): French translation upload and provenance export

[SanjeevLakhwani]

Summary

Redmine ticket 2830
Requires: bento-platform/katsu#705

• Adds a typed API layer (src/api/datasetTranslations.ts) for the katsu translation endpoints (GET/POST/PUT /api/datasets/{id}/translations/{lang}), with bearer token support via useAuthorizationHeader
• Adds a French Translation modal on each dataset card that checks for an existing translation on open and presents a drag-and-drop JSON upload; validates locally with Zod, posts to the API, and displays DRF field-keyed errors inline
• The translation button label dynamically reflects whether a translation exists ("Add French Translation" / "Edit French Translation") by probing the API on mount and after the modal closes
• Adds an Export dropdown next to "View Provenance" with options for English (canonical, downloaded instantly from local state) and French (fetched then downloaded); the French option is hidden when no translation exists

[gsfk]

I'll have to throw together some examples for testing I guess.... first comment is that it's unconditionally checking for translations for each dataset, producing a lot of calls with 404 errors and jamming up my console.

[gsfk]

Also not sure what you mean by "private" mode in bento_web.

[gsfk]

I honestly find this extremely hard to work with:

• Is there a better way to check for existing translations than checking if calls are 404? This litters my console and network tab with errors and makes development harder. It is particularly bad for multiple datasets.
• There are now lots of buttons on the dataset card, with overlapping uses, arguably the new export and translation buttons belong inside the Provenance modal. ("Export" at the top level of a dataset arguably should mean "export data").
• Validation does not work as promised. Most validation errors just produce the antd error message "JSON validation failed: Invalid input" with no more details, even in the browser console (instead your console is just 404 errors).
• A small number of errors will produce the zod validation error message. But if you add to your JSON one of the many kinds of errors that produce only the antd message, you will lose your zod feedback (i.e. antd always dominates).
• I also had one zod feedback message that appeared but then disappeared when the modal tried to recheck for an existing translation.
• This pr continues the creep towards using the word "Provenance" to mean the entire dataset model, I find this confusing. I'm no longer even sure what provenance is supposed to be.
• it ignores existing French translations of discovery fields, even though discovery fields are included in "Export".
• when a translation exists, the button changes name to "Edit French Translation", but then on clicking it will sometimes go through the routine of checking for an existing translation again.

[gsfk]

Much nicer than yesterday, although more comments:

• found an existing bug: the "Remove" buttons in dataset editing don't work, the fields persist, even after hard refresh. For the "counts" field you can even see the data you deleted reappear in the UI when you close the modal.
• zod error messages persist after closing
• can we go back to plain old "Edit" for the button text instead of "Provenance"?
• is there a way to tell which fields it will actually use the translation for? There are some fields where it probably shouldn't accept a translation at all, like PCGL DAC ID.
• it accepts translations for the entire discovery config but ignores them.

[gsfk]

• "Remove" is still broken
• repeating my question whether the "edit/view dataset information" button needs to be called "Provenance", this is probably worth discussing in a meeting

[gsfk]

Seems good. I think most of the annoyances and edge cases are gone. The few that remain arguably aren't that interesting, for example the translation can add fields, but is never permitted to remove them.