DeleteTagExtendedProperties: confirm walled via native capture (do not ship)

Tested the binary-dive "use deleteFromServer=true" hypothesis directly against
the native client (local 2020 WCF box, Capture-DeleteTagExtendedProperties.ps1
cross-session sync trick). Result: the native DeleteTagExtendedPropertiesByName
with deleteFromServer=true returns Success=true, but the property is re-fetchable
and re-deletable across repeated fresh sessions — it is NEVER durably removed.

So the native client itself only performs an optimistic client-side cache delete
the server does not durably honor (the HCAL cache-sync model the decompile shows).
This supersedes the earlier "code=1, prop survives" note (that was the same-session
sync-gate failure; with proper cross-session sync it returns Success yet still does
not durably delete). A managed DeleteTagExtendedPropertiesAsync would return a
misleading success, so it correctly stays unshipped. Handoff item 7 updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B6mcaT2PjRFKcogzp9UkfC

docs/reverse-engineering/handoff.md

@@ -91,13 +91,18 @@ reuses the proven 2020 WCF byte serializers/parsers unchanged inside protobuf
    RegisterTags prime doesn't help). Use WCF for SQL.
 5. **R4.2 revision EDITS** — storage-engine-pipe-only on BOTH transports (the D2 wall).
 6. **ReadBlocks** (`StartBlockRetrievalQuery`) — never captured on either transport.
-7. **DeleteTagExtendedProperties** — server-blocked on BOTH transports. The gRPC
-   multiplexed-channel hypothesis was **PROBED + DISPROVEN 2026-06-22** (merge
-   `c88260c`): GetTgByNm + GetTepByNm primes succeed on one shared write-enabled
-   gRPC channel, yet DelTep is still rejected (native code=1) and the property
-   survives — the working set is native in-process registration state, not the
-   wire session. Pinned by gated negative test
-   `DeleteTagExtendedProperties_OverGrpc_ProbeMultiplexedChannel`.
+7. **DeleteTagExtendedProperties** — server-blocked; **confirmed walled by capturing the NATIVE
+   client 2026-06-23.** The agent's "use `deleteFromServer=true`" angle is moot: the native
+   `HistorianAccess.DeleteTagExtendedPropertiesByName(...,deleteFromServer:true)`, driven with the
+   cross-session sync trick that gets it past the client-side err-229 sync gate
+   (`Capture-DeleteTagExtendedProperties.ps1`), returns **`Success=true` / ErrorCode=Success** —
+   yet across repeated fresh sessions the property is **re-fetchable and re-deletable every time**,
+   i.e. it is **never durably removed**. So the native client itself only performs an optimistic
+   client-side cache delete; the server does not durably honor it (matches the HCAL cache-sync
+   model the decompile shows). Shipping a `DeleteTagExtendedPropertiesAsync` would return a
+   misleading success while the property persists, so it correctly stays **unshipped**. (Earlier
+   gRPC multiplexed-channel hypothesis also PROBED + DISPROVEN 2026-06-22, merge `c88260c`; pinned
+   by `DeleteTagExtendedProperties_OverGrpc_ProbeMultiplexedChannel`.)
 8. **Deferred-by-design** items (`write-commands` D1–D3, non-analog tag create,
    etc.) — bounded out until an explicit customer/user demand signal.
 
@@ -159,15 +164,15 @@ with these refinements:
   handle+sequence cursor but the `historyBlocks` response is a native blob with no
   managed decoder, and it needs the D2-blocked `OpenStorageConnection` console handle.
   Walled.
-- **Item 7 (DeleteTagExtendedProperties)** — **reframed to a capturable lead.** RPC +
-  string handle are **correct** in our SDK; ADD and DELETE are structurally identical
-  and **neither** routes through `StartJob`. The differentiator is the `deleteFromServer`
-  flag carried inside the native-built `BtInput` plus the native HCAL **cache-sync
-  background worker** that actually propagates the delete server-side (config writes hit
-  the in-process cache first, then sync). **Capturable**: capture native
-  `DeleteTagExtendedPropertiesByName(deleteFromServer=true)`'s `BtInput` to learn whether
-  one well-formed RPC durably deletes (→ shippable) or whether it genuinely depends on
-  the cache-sync worker (→ walled).
+- **Item 7 (DeleteTagExtendedProperties)** — **capture done 2026-06-23; CONFIRMED WALLED, don't
+  ship.** RPC + string handle are correct; ADD/DELETE are structurally identical and neither uses
+  `StartJob`. The `deleteFromServer`-flag hypothesis is now tested and moot: the native
+  `DeleteTagExtendedPropertiesByName(...,deleteFromServer:true)`, driven past the err-229 client
+  sync gate with the cross-session trick (`Capture-DeleteTagExtendedProperties.ps1`), returns
+  `Success=true` — yet the property is **re-fetchable + re-deletable across repeated fresh sessions
+  (never durably removed)**. So the native client only does an optimistic client-side cache delete
+  the server doesn't durably honor (the HCAL cache-sync model). Shipping
+  `DeleteTagExtendedPropertiesAsync` would return a misleading success, so it stays unshipped.
 - **SF/snapshot/shard/ForwardSnapshot ops** — only `Get/SetSFParameter` are managed-built
   (typed strings); all others carry opaque native buffers and need the storage console
   handle. Walled / tooling-internal.