build(sonar): exclude generated fbs/proto from analysis; document dup trade-off

Generated FlatBuffers/Protobuf sources were excluded from coverage only,
so their machine-style naming and copy-shaped accessors still contributed
~160 code smells and padded the duplication metric. Add sonar.exclusions
to drop them from analysis entirely.

ADR 0005 gains a Consequences note: per-width/per-ptype loop duplication
(unpackLoop16/32/64 etc.) is a deliberate cost of keeping hot-loop bodies
uniform for C2 auto-vectorization, not a defect to refactor away.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: dfa1

docs/adr/0005-vector-api-adoption.md

@@ -120,6 +120,27 @@ loop structure.
 - If Vector API finalizes and shows large gains, this deferral costs
   time. Mitigation: the TODO items remain; the ADR is the trigger to
   act when conditions are met, not a permanent block.
+- **Code duplication is a deliberate cost of the auto-vectorization
+  strategy.** Keeping each hot loop's body uniform (condition for C2
+  superword) forces *monomorphization* — one specialized copy per element
+  width / ptype rather than a shared generic loop. `BitpackedEncodingDecoder`
+  carries `unpackLoop16` / `unpackLoop32` / `unpackLoop64`, three ~96-line
+  methods identical except for their `2L`/`4L`/`8L` strides and
+  `LE_SHORT`/`LE_INT`/`LE_LONG` accessors (~254 duplicated lines, ~48%
+  of the file). They cannot be merged: a single generic loop parameterized
+  by element width reintroduces a per-element variable-width branch, which
+  is exactly what makes C2 refuse to vectorize. The same trade-off produces
+  the per-ptype duplication in `DeltaEncodingEncoder`, `AlpEncodingEncoder`,
+  and the FrameOfReference paths.
+
+  Consequence for tooling: SonarCloud reports this as duplication
+  (project density ~4.7%, dominated by these files). That number is
+  expected and should not be "fixed" by collapsing the loops — doing so
+  would regress throughput. If the metric becomes noisy, suppress it for
+  the specialized decoders via `sonar.cpd.exclusions` rather than
+  refactoring. (Generated `fbs/`/`proto/` sources are already excluded
+  from analysis via `sonar.exclusions` for the same reason — machine
+  output, not hand-maintained code.)
 
 ### Risk
 - If a downstream consumer benchmarks the library and finds a

pom.xml

@@ -86,6 +86,15 @@
 			**/proto/**,
 			**/performance/**
 		</sonar.coverage.exclusions>
+		<!-- Generated FlatBuffers/Protobuf sources under fbs/ and proto/ are emitted
+		     verbatim by external code-gen and never hand-edited. Their machine style
+		     (getRootAsX naming, redundant casts) trips ~160 smells and pads the
+		     duplication metric with copy-shaped accessors, all unactionable noise.
+		     Exclude from analysis entirely, not just coverage. -->
+		<sonar.exclusions>
+			**/fbs/**,
+			**/proto/**
+		</sonar.exclusions>
 		<!-- Coverage sources:
 		     1. per-module surefire (unit tests)
 		     2. per-module failsafe (module-local integration tests)