fix: address all 9 findings from final calibration code review

- calibration.js: fix baseSignalName('[0]') parity with Go/C++ (>= 0 not > 0)
- calibration.test.js: add assertions for '[0]' edge case in two existing tests
- app.js: remove stale typeof guard around refreshVScaleMenu (always defined)
- app.js: call refreshTrigThresholdField on trig-signal change (both assignment sites)
- index.html: drop maxlength='16' on unit input; normaliseCal is the sole enforcer
- configcheck/main.go: delete dead nextOneOf function (no callers)
- hub_calibration_test.go: delete orphaned waitBroadcast comment (function never existed)
- calibration.go: correct arrayIndexSuffix comment to document known Go/C++ difference
- Docs/StreamHub-API.md: add calibration entry count and unit byte limits to §5 table
- spec: fix configReloaded missing path field, '16 chars'→'16 UTF-8 bytes', StreamString→char[], chain scenario→configcheck program, four→five new frames

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Common/Client/go/wshub/calibration.go

@@ -13,7 +13,14 @@ import (
 
 // arrayIndexSuffix matches a trailing "[digits]" at the very end of a signal
 // name, used to strip array-element suffixes so one entry covers the whole
-// array.  Mirrors the C++ `strchr(signal,'[')` truncation and the JS equivalent.
+// array.  The regexp is anchored to the end of the string and requires digits,
+// so it only removes a well-formed trailing element index: "Adc[3]" → "Adc",
+// "[0]" → "", "A[1]B" → "A[1]B" (no match).
+//
+// Known difference vs C++: the C++ hub uses strchr(signal,'[') which finds the
+// FIRST '[' anywhere in the name, so C++ reduces "A[1]B" to "A" while this
+// regexp leaves it unchanged.  Both implementations agree on the common cases
+// ("Name[i]" and "[i]" alone) that arise from real UDPS signal names.
 var arrayIndexSuffix = regexp.MustCompile(`\[\d+\]$`)
 
 // maxUnitLen bounds the calibration unit override.  Mirrored by kMaxUnitLen in