build-number

Record the locales a bundle serves as drb.locales A consumer that wants to offer regional variants of a language -- se-NO vs se-SE, sjd-RU -- has had to carry its own language table to know which regions exist. The LibreOffice extension ships a 332-entry locales.json scraped from LibreOffice's isolang.cxx in 2022 for exactly this, and it goes stale the moment a language is added. The language repos already declare this, in manifest.toml's windows.extra_locales: { se-NO = "se", se-SE = "se", se-FI = "se" } for sme, { sjd-RU = "sjd" } for sjd. Carry it into the bundle so the fact travels with the artifact instead of being duplicated per consumer. bundle --locales "se-NO,se-SE,se-FI" -> drb.locales alongside the existing drb.type/name/version, and shown by `list`. Reading it needs a C-ABI accessor, and the two added here are general rather than one-per-attribute: DRT_Bundle_metadataAttr and DRT_Bundle_metadataKeys. Both take a path, not a bundle handle, and read the box trailer only -- no pipeline parse, no asset access -- because the caller wants to scan every installed bundle at startup and some are over a gigabyte. An absent key returns an empty slice and does not raise, so bundles built before this attribute existed read as absent rather than failing; consumers keep their fallback until bundles are rebuilt. divvun-runtime deliberately does not learn to read manifest.toml: it is a generic tool and manifest.toml is a Divvun packaging convention, so the value arrives as a CLI argument exactly like type/name/version do. Verified end to end over the C ABI: " sjd-RU , , se-NO " normalises to "sjd-RU,se-NO", and the installed sjd.drb (built before this) reports keys ["drb.type","drb.name","drb.version"] with drb.locales absent.