0.2.1 — append Config's new fields instead of inserting them - #6

0.2.0 added requireSignedConfig and keylessHeartbeatIntervalMs in the MIDDLE of
Config, ahead of autoValidationIntervalMs. Positional aggregate initialisation
binds by position, so `Config cfg{"tenant", "product", ..., 60000}` written
against 0.1.6 either shifted every value after the insertion point or stopped
compiling — a break bought for nothing, since appending costs the same.
This repo already documents the rule twice, on State::FreeTier and
State::Limited, for exactly this reason. I did not follow it on Config. The
struct now carries the same note, so the next field goes on the end.
Nothing else changes: same fields, same names, same defaults, same behaviour.
Only positional aggregate initialisation was ever affected, and the documented
style is field assignment. Anyone still on 0.1.6 should upgrade straight to
0.2.1 and skip the question.
The porting handoff gains this as a fourth trap, since the rule holds in the
other SDKs through different mechanisms: Swift's memberwise initialiser takes
arguments in declaration order, and in Rust adding a public field at all breaks
construction without ..Default::default() unless the struct is non_exhaustive.
JS and C# are name-based and unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>