WenoStencil: self-contained Taps tuple, no more Weno5Stencil policy dep

Consolidates the 19-tap WENO5 tuple into WenoStencil<W> itself, drops
the external dependency on StencilAccessor.h, and removes references
to the Weno5Stencil policy struct / Hull (neither needed now that the
hybrid SIMD StencilAccessor is on the way out per the cleanup plan).

Before:
  WenoStencil.h  -> #include <StencilAccessor.h>
                    using Taps = Weno5Stencil::Taps;
                    tapIndex() -> detail::findIndex<Taps, ...>();

After:
  WenoStencil.h  -> self-contained; no accessor include
                    nested TapPoint<DI,DJ,DK> as the tap-offset type
                    nested using Taps = std::tuple<TapPoint<...>, ...>;
                    private static findTap<DI,DJ,DK>() helper
                    (compile-time inverse map, same pattern as the
                    ex-detail::findIndex)

Tap ordering unchanged — canonical WenoPt<i,j,k>::idx convention
(center, x-axis -3..+3, y-axis -3..+3, z-axis -3..+3).  Hull
intentionally absent (was only consumed by the hybrid StencilAccessor
prefetch path, which is no longer exercised).

StencilAccessor.h is left alone this pass: it still defines its own
StencilPoint + detail::findIndex + Weno5Stencil policy (with both
Taps and Hull) for the benchmark passes that still instantiate
StencilAccessor<..., Weno5Stencil>.  Those will fall away when the
hybrid path is removed in a subsequent cleanup step; the decoupling
here is preparation for that.

LegacyStencilAccessor.h also unchanged — it still includes
StencilAccessor.h for StencilPoint/findIndex, and its callers use
Weno5Stencil as the policy type.  WenoStencil<W>::Taps could replace
that role later, but since W=1 vs W=16 stencils would pin the policy
to a specific lane width, the more natural move is to introduce a
standalone tap-tuple header when StencilAccessor.h retires.

Verification on taperLER.vdb (31.8M active voxels, 24 threads):
  - ex_weno_nanovdb_cpu, ex_narrowband_stencil_cpu,
    ex_stencil_gather_cpu all rebuild and link clean.
  - ex_weno_nanovdb_cpu output identical (slot-by-slot) to pre-refactor:
      73.75% bit-exact, 3.53% in [1e-8,1e-7), 22.72% in [1e-7,1e-6),
      0 voxels above 1e-6; max |Delta|=9.5e-7 at the same slot as before.
  - Timings within noise (94.8 ms fast / 121.1 ms reference).

WenoStencil.md:
  - §3.3 text refreshed: kPairs indices now cross-reference
    WenoStencil<W>::Taps rather than Weno5Stencil::Taps.
  - §5.3 tapIndex forwarding reference: detail::findIndex -> private
    static findTap.
  - §7.2 (the old "Consolidate the Weno5Stencil policy" to-do) removed;
    the consolidation it proposed is this commit.  §7.3 renumbered to §7.2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Efty Sifakis <esifakis@nvidia.com>

Author: sifakis

nanovdb/nanovdb/util/WenoStencil.h

@@ -40,7 +40,6 @@
 #pragma once
 
 #include <nanovdb/util/Simd.h>
-#include <nanovdb/util/StencilAccessor.h>  // StencilPoint, Weno5Stencil, detail::findIndex
 #include <nanovdb/math/Math.h>             // Pow2
 
 #include <cstdint>
@@ -132,12 +131,35 @@ template<int W = 1>
 class WenoStencil
 {
 public:
-    static constexpr int SIZE = 19;
-
-    using Taps   = Weno5Stencil::Taps;
     using FloatV = util::Simd    <float, W>;
     using MaskV  = util::SimdMask<float, W>;
 
+    // --- Tap-offset types (compile-time only) -----------------------------
+    // TapPoint<DI,DJ,DK> carries the tap offset as a type.  Taps is the
+    // 19-tap tuple in the canonical WenoPt<i,j,k>::idx ordering from
+    // nanovdb/math/Stencils.h:
+    //    idx  0     : center  < 0, 0, 0>
+    //    idx  1.. 6 : x-axis  <-3,0,0> <-2,0,0> <-1,0,0> <+1,0,0> <+2,0,0> <+3,0,0>
+    //    idx  7..12 : y-axis  <0,-3,0> <0,-2,0> <0,-1,0> <0,+1,0> <0,+2,0> <0,+3,0>
+    //    idx 13..18 : z-axis  <0,0,-3> <0,0,-2> <0,0,-1> <0,0,+1> <0,0,+2> <0,0,+3>
+    template<int DI, int DJ, int DK>
+    struct TapPoint {
+        static constexpr int di = DI, dj = DJ, dk = DK;
+    };
+
+    using Taps = std::tuple<
+        TapPoint< 0, 0, 0>,
+        TapPoint<-3, 0, 0>, TapPoint<-2, 0, 0>, TapPoint<-1, 0, 0>,
+        TapPoint<+1, 0, 0>, TapPoint<+2, 0, 0>, TapPoint<+3, 0, 0>,
+        TapPoint< 0,-3, 0>, TapPoint< 0,-2, 0>, TapPoint< 0,-1, 0>,
+        TapPoint< 0,+1, 0>, TapPoint< 0,+2, 0>, TapPoint< 0,+3, 0>,
+        TapPoint< 0, 0,-3>, TapPoint< 0, 0,-2>, TapPoint< 0, 0,-1>,
+        TapPoint< 0, 0,+1>, TapPoint< 0, 0,+2>, TapPoint< 0, 0,+3>
+    >;
+
+    static constexpr int SIZE = int(std::tuple_size_v<Taps>);
+    static constexpr int size() { return SIZE; }
+
     // Compute-side storage — first-class Simd values.  At W=1 these collapse
     // to plain scalar float / bool under the array backend.
     FloatV values  [SIZE];
@@ -154,17 +176,13 @@ class WenoStencil
     NANOVDB_SIMD_HOSTDEV explicit WenoStencil(float dx)
         : mDx2(dx * dx), mInvDx2(1.f / (dx * dx)) {}
 
-    static constexpr int size() { return SIZE; }
-
     // Compile-time named-tap access: returns the index of tap (DI,DJ,DK) in
     // the Taps tuple.  Ordering matches WenoPt<i,j,k>::idx in
-    // nanovdb/math/Stencils.h, so this is interoperable with canonical WENO
-    // index conventions.
+    // nanovdb/math/Stencils.h.
     template<int DI, int DJ, int DK>
     static constexpr int tapIndex()
     {
-        constexpr int I = detail::findIndex<Taps, DI, DJ, DK>(
-            std::make_index_sequence<SIZE>{});
+        constexpr int I = findTap<DI, DJ, DK>(std::make_index_sequence<SIZE>{});
         static_assert(I >= 0, "WenoStencil::tapIndex: tap not in stencil");
         return I;
     }
@@ -200,8 +218,22 @@ class WenoStencil
     [[gnu::always_inline]] NANOVDB_SIMD_HOSTDEV inline FloatV normSqGrad(float iso = 0.f) const;
 
 private:
-    // Hardcoded (tap, innerTap) pairs for Weno5Stencil::Taps, ordered by
-    // ascending |Δ|.  Indices match the tuple definition in StencilAccessor.h.
+    // Compile-time inverse map: (DI,DJ,DK) → slot index in Taps.  Returns -1
+    // if no matching tap exists; tapIndex() turns that into a static_assert.
+    template<int DI, int DJ, int DK, size_t... Is>
+    static constexpr int findTap(std::index_sequence<Is...>)
+    {
+        int result = -1;
+        ((std::tuple_element_t<Is, Taps>::di == DI &&
+          std::tuple_element_t<Is, Taps>::dj == DJ &&
+          std::tuple_element_t<Is, Taps>::dk == DK &&
+          result < 0 ? (result = int(Is)) : 0), ...);
+        return result;
+    }
+
+    // Hardcoded (tap, innerTap) pairs for the 19-tap Taps tuple, ordered by
+    // ascending |Δ| so the inner tap is always already resolved when the
+    // outer tap is processed.  Indices match the Taps tuple above.
     //
     //   idx  0     :  center     ( 0, 0, 0)
     //   idx  1.. 6 :  x-axis     (-3..+3 in the order -3,-2,-1,+1,+2,+3)

nanovdb/nanovdb/util/WenoStencil.md

@@ -164,8 +164,8 @@ outer tap is processed.  Sign propagation through a |Δ|=1 → |Δ|=2 →
 
 ### 3.3  The `kPairs[]` table
 
-The inner-tap relationship is `Weno5Stencil`-specific and hardcoded as
-a static table inside the class:
+The inner-tap relationship is WENO5-specific and hardcoded as a static
+table inside the class:
 
 ```cpp
 static constexpr int kPairs[18][2] = {
@@ -178,16 +178,16 @@ static constexpr int kPairs[18][2] = {
 };
 ```
 
-Indices match the tuple ordering in `Weno5Stencil::Taps`
-(`StencilAccessor.h`) and `WenoPt<i,j,k>::idx` in
-`nanovdb/math/Stencils.h`.  Center tap (idx 0) is not processed —
+Indices match the `WenoStencil<W>::Taps` tuple defined in
+`WenoStencil.h` (same ordering as `WenoPt<i,j,k>::idx` in
+`nanovdb/math/Stencils.h`).  Center tap (idx 0) is not processed —
 assumed always in-band.
 
 **Why hardcoded, not template-derived:**  a generic scheme would walk
-`Weno5Stencil::Taps` at compile time and derive inner-tap indices from
-|Δ| and axis alignment.  For a single stencil the table is 18 entries,
-reads directly, and makes the cascade ordering self-documenting.
-Worth revisiting if we add Weno7 or other axis-aligned WENO variants.
+`Taps` at compile time and derive inner-tap indices from |Δ| and axis
+alignment.  For a single stencil the table is 18 entries, reads
+directly, and makes the cascade ordering self-documenting.  Worth
+revisiting if we add Weno7 or other axis-aligned WENO variants.
 
 ### 3.4  `extrapolate()` implementation
 
@@ -378,9 +378,9 @@ constexpr int xm3 = WenoStencil<W>::tapIndex<-3, 0, 0>();
 FloatV xm3Value   = stencil.values[xm3];
 ```
 
-`tapIndex<DI,DJ,DK>()` forwards to `detail::findIndex` (shared with
-`StencilAccessor`), static-asserting at compile time that the
-requested tap exists in the Weno5Stencil::Taps tuple.
+`tapIndex<DI,DJ,DK>()` forwards to a private static `findTap` helper
+inside `WenoStencil<W>`, static-asserting at compile time that the
+requested tap exists in the `Taps` tuple.
 
 ---
 
@@ -428,20 +428,11 @@ taperLER.vdb; compare against `sidecar-stencil-extrap` (which writes
 the tap-sum instead of normSqGrad) to isolate the Phase-3 arithmetic
 cost.
 
-### 7.2  Consolidate the Weno5Stencil policy
-
-Currently `Weno5Stencil` (the tap-tuple policy struct) lives in
-`StencilAccessor.h` and is shared with `WenoStencil<W>` via
-`using Taps = Weno5Stencil::Taps`.  The policy is arguably a
-Weno-specific definition and could move into `WenoStencil.h`;
-`StencilAccessor.h` would then `#include <.../WenoStencil.h>` for the
-policy.  Left as-is to minimise churn across files.
-
-### 7.3  Alternative stencils
+### 7.2  Alternative stencils
 
 If/when Weno7 or a non-axis-aligned stencil is needed, the class
 would specialise on a stencil-policy template parameter rather than
-hardcode `Weno5Stencil`:
+hardcoding the 19-tap WENO5 shape:
 
 ```cpp
 template<typename StencilPolicy, int W>