Carry the build config key onto repository build definitions

[melindash]

mergeBuildConfigs constructs each instruction with Object.assign({key}, ...), but the repositoryBuildDefinition constructor never copied options.key, so instruction.key was always undefined.

That makes the per-repository branch of the release refs lookup in mageos-release.js unreachable:

if (releaseRefs['']) instruction.ref = releaseRefs[''];
if (releaseRefs[instruction.key]) instruction.ref = releaseRefs[instruction.key];

Only the global '*' override could ever apply, so a release could not build one repository from a different ref to the rest. With the key carried through,

module.exports = {'*': 'main', magento2: 'release/3.x'};

builds magento2 from a release branch while the other 24 repositories stay on main, which avoids having to create and maintain a branch group across every repository in releaseBuildConfig.

A full release build produces identical output with and without this change when tested locally.

[rhoerr]

Confirmed — on main all 25 instructions have key === undefined, so the per-repo branch at mageos-release.js:103 was unreachable. Fix is right, suite stays green at 897.

One ask: tests/unit/utils.test.js:494 is already named should include key from b in result and its comment says it verifies the key — but the body only asserts toHaveLength(1), so it passed through the whole bug. Adding expect(result[0].key).toBe('my-repo'); there pins this at the exact seam. Two more lines in tests/unit/type/repository-build-definition.test.js (key alongside ref in the default values / provided values blocks) cover the constructor.

With those, I'd drop the new test file — its resolveRefs helper re-implements the resolution order it's testing, so it wouldn't catch a change to the real one.

Happy to merge once that lands.