R1.11 DelTep capture + R1.3/R1.4/R1.12/R1.13 bounded out

DelTep (extended-property delete) — wire format captured + serializer
golden-proven, but live delete is server-blocked and NOT exposed publicly:
- Captured the DelTep inBuff via a cross-session trick (harness add-tep gains
  --tep-skip-add + read-for-sync before --tep-delete; Capture-DeleteTagExtended
  Properties.ps1 / decode-del-tep-capture.py). Layout = same group framing as
  AddTEx but property-name-only (no 0x43 value) + 0x00 group trailer.
- SerializeDeleteRequest + 4 golden tests pin the server-accepted buffer.
- A decisive experiment shows SDK-added properties ARE deletable (the native
  client read-syncs and deletes one), so SDK-add is complete; the SDK's own
  DelTep is rejected by CHistStorage::DeleteTagExtendedProperties even with
  byte-identical inBuff, matching mode/handle, GetTgByNm+GetTepByNm prime, open
  channel, and 60s retries. Root cause: the native multiplexes services over one
  connection (per-connection working set); the SDK's per-service WCF channels
  don't reproduce it. Kept as documented-but-blocked internal orchestrator path;
  no public HistorianClient delete API.

Bounded out with evidence (no code; docs + roadmap + probe):
- R1.12 localized-property write — no op on 2020 (mirror of R1.6); no
  *LocalizedPropert*/TagLocalized* symbol in any current/*.dll.
- R1.13 non-analog tag create — GATED; native AddTag rejects every non-analog
  type client-side (ValidationFailed, before any WCF op): SingleByteString,
  DoubleByteString, Int1 all fail, Float works. No Discrete type in the native
  enum, no TagType setter. No wire request to capture.
- R1.3 timezone + R1.4 EventStorageMode — re-confirmed 2023R2/gRPC-only from
  the Runtime DB schema (no timezone param, no EventStorageMode anywhere) and a
  parameter-op probe (GetSystemParameter + GETRP return null/throw for every
  candidate; only HistorianVersion works).

238 unit tests pass; full solution builds with 0 warnings.

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

docs/reverse-engineering/wcf-status-localhost.md

@@ -71,3 +71,31 @@ Findings:
 Shipped as `HistorianClient.GetRuntimeParameterAsync(name)`. See
 `HistorianRuntimeParameterProtocol`, golden `WcfRuntimeParameterProtocolTests`, and the
 handle-format lead in `wcf-string-handle-wall.md` §Update (retry GETHI/ExeC uppercased).
+
+## R1.3 timezone + R1.4 EventStorageMode — re-confirmed bounded out (2026-06-21)
+
+Both were already classified 2023R2/gRPC-only; re-verified from two *fresh* angles that corroborate it
+more strongly than the original op-level probes:
+
+- **Runtime DB schema** (`Runtime.dbo`, the server's own source of truth): the `SystemParameter` table
+  has **no** timezone parameter and **no `EventStorageMode`** (only `EventStorageDuration` /
+  `EventStorageLogPath`). The server timezone exists only as **per-block storage artifacts**
+  (`HistoryBlock.TimeZoneOffset` = e.g. 240 min, `wwTimeZone` = e.g. "Eastern Daylight Time") and a
+  `TimeZone` reference/lookup table; `StorageShard.TimeZoneId` is NULL. So the timezone is a
+  DST-specific, SQL-only, OS-derived value, not a clean server-config field exposed by any op.
+- **Parameter-op probe** (`StringHandleProbeDiagnosticTests.TimezoneAndStorageMode_ParameterProbe`):
+  `GetSystemParameter` and `GetRuntimeParameter` (GETRP) were asked for every timezone candidate
+  (`TimeZone`/`ServerTimeZone`/`SystemTimeZone`/`TimeZoneName`/`SystemTimeZoneName`/`TimeStampRule`/
+  `ServerTime`) and every storage-mode candidate (`EventStorageMode`/`StorageMode`/`EventStorage`/
+  `EventStorageDuration`). **All returned null (GetSystemParameter) or threw
+  `ProtocolEvidenceMissingException` (GETRP — non-string/empty response)**; only the `HistorianVersion`
+  control returned a value (`20,0,000,000`). Note: `TimeStampRule`/`EventStorageDuration` *do* exist in
+  the `SystemParameter` table yet `GetSystemParameterAsync` returns null for them — the shipped op only
+  surfaces a whitelisted subset (a possible future widening, unrelated to R1.3/R1.4).
+
+Conclusion: **R1.3 `GetServerTimeZoneAsync` and R1.4 `GetHistorianInfoAsync` (EventStorageMode) are not
+deliverable as server ops on 2020.** The only 2020 route to the timezone is a SQL read of
+`HistoryBlock`/`TimeZone` via `ExecuteSqlCommand` (R1.1) — a DST-specific value over a different
+mechanism than the roadmap's `Status.GetSystemTimeZoneName`. `EventStorageMode` has no 2020
+representation at all (it is a 2023 R2 event-storage-architecture field). Deliver both only against a
+live 2023 R2 gRPC server.