zephyr-cp: stop non-English builds from linking the English translation objects

[dhalbert]

Claude found and fixed this, reviewed and tested on hardware by @dhalbert.

Every non-en_US zephyr-cp firmware built by CI contains the English compressed strings together with the other language's decompression tables. This breaks the firmware: @dhalbert tested the 10.3.1 fr build on a Feather RP2040. It enumerates CIRCUITPY but its REPL never responds because of the scrambled compressed strings; en_US works.

The cause

cpbuild.archive() updated libcircuitpython.a with ar rvs, which replaces the members named on the command line and keeps every other member. The release build reuses one build directory for all 17 languages, so after en_US each later language added its own translations-<lang>.o and autogen_display_resources-<lang>.o, but the en_US members stayed in the archive ahead of them and the linker took those. translate.c, which holds the decompression tables, is recompiled per language, so strings and tables no longer match.

Evidence from the artifacts of today's main run for adafruit_feather_nrf52840_zephyr: all 516 compressed translation symbols in the de_DE and ja ELFs have exactly the sizes they have in en_US, while a clean local de_DE build differs in 426 of them. The linker map of an incremental de_DE build shows libcircuitpython.a(translations-en_US.o).

Fix

Delete the archive, and then use ar rcs, so it only ever contains the current build's objects. The c in ar rcs prevents a warning that the archive had to be created.

The archive is now rebuilt on every build, which is under a second for ~450 objects.

Verification

• Incremental en_US then de_DE on adafruit_feather_nrf52840_zephyr is now byte-identical to a clean de_DE build at the same path; ja matches the clean ja size, and the map shows only the current language's objects.
• Tested by @dhalbert: adafruit_feather_rp2040_zephyr: en_US, then fr, then ja built in one directory and flashed in turn; the fr and ja REPLs work and show their languages.
• cptools tests pass.

Affects every zephyr-cp release with translations, so this has been broken for a while.

[mikeysklar]

Tested this PR with 10.3.x and main, building adafruit_feather_nrf52840_zephyr en_US then fr in one directory. On a Feather nRF52840, unpatched 10.3.x fr never enumerates on USB. With this change both fr builds boot with a French REPL. Should this also go into 10.3.x?

[dhalbert]

Should this also go into 10.3.x?

Probably anyone using the zephyr builds is going to be willing to use the alpha builds, since the zephyr port is alpha anyway. So I would say not worth it.