docs: scrub internal increment numbering from public code comments

Reword doc-comments and test section headers that referenced internal
workstream increment numbers to describe the mechanism instead (the
channel-register block-event fold, the verification-merge hook). The
numbers are private-tracker vocabulary with no meaning to an external
reader. Comment-only; no logic change.

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

Author: bond00729

src/network/http_server.rs

@@ -4672,7 +4672,7 @@ mod tests {
     fn channel_owner_change_hint_cause_maps_every_variant() {
         // The proto->JSON cause conversion is a hand-written int->variant table; the round-trip
         // test above only exercises TRANSFER. Pin every arm (0..=4) plus the unknown-int
-        // fallback: the NEXT increment starts emitting REGISTER/VERIFICATION_* hints, so the
+        // fallback: the ownership-hint feature emits REGISTER/VERIFICATION_* hints, so the
         // arms about to go live are otherwise untested, and a transposition or a wrong fallback
         // on this public wire contract would ship silently. The unknown case also freezes the
         // intended forward-compat behavior (a future proto cause degrades to NONE, not a panic).

src/storage/store/account/onchain_event_store.rs

@@ -452,7 +452,7 @@ fn build_secondary_indices_for_channel_register(
     Ok(change)
 }
 
-/// Data-shard replica entry point (increment 7): runs ONLY the channel-register
+/// Data-shard replica entry point: runs ONLY the channel-register
 /// secondary-index fold against `db`/`txn` — it does not write the primary
 /// onchain-event record and does not touch the trie (those live in the shard-0
 /// merge path). Non-channel events fold to `None`. Returns the ownership change a

src/storage/store/block_engine_tests.rs

@@ -302,7 +302,7 @@ mod tests {
             .is_none());
     }
 
-    // --- Shard-0 fan-out of channel-register events (increment 7) -----------------------------
+    // --- Shard-0 fan-out of channel-register events -------------------------------------------
 
     fn single_channel_register(channel_key: &str, owner_byte: u8) -> OnChainEvent {
         events_factory::create_channel_register_event(

src/storage/store/engine.rs

@@ -816,7 +816,7 @@ impl ShardEngine {
     /// Emit `ChannelOwnerChangeHint` HubEvents for a just-merged Ethereum
     /// verification whose verified address owns one or more channels, by scanning
     /// THIS shard's own ByOwnerAddress replica (the trie-free ownership index built
-    /// by the increment-7 block-event fold). Called only from the user-message
+    /// by the channel-register block-event fold). Called only from the user-message
     /// merge loop's `Ok(merge_events)` arm — the hottest path this feature touches.
     ///
     /// STRUCTURAL SAFETY CONTRACT (the rule this increment lives or dies by): this

src/storage/store/engine_tests.rs

@@ -4489,7 +4489,7 @@ mod tests {
     }
 
     // ----------------------------------------------------------------------------------------
-    // MergeOnChainEvent BlockEvent replica fold + ownership hints (increment 7).
+    // MergeOnChainEvent BlockEvent replica fold + ownership hints.
     //
     // Shard 0 fans channel-register events to every data shard as a MergeOnChainEvent BlockEvent;
     // `handle_block_event` runs the trie-free replica fold against the shard's own
@@ -4950,10 +4950,10 @@ mod tests {
     }
 
     // ----------------------------------------------------------------------------------------
-    // Verification-merge channel-owner hints (increment 8).
+    // Verification-merge channel-owner hints.
     //
     // When an Ethereum verification merges on the user-message path, the engine scans THIS
-    // shard's own ByOwnerAddress replica (built by the increment-7 block-event fold) and emits
+    // shard's own ByOwnerAddress replica (built by the channel-register block-event fold) and emits
     // one ChannelOwnerChangeHint per channel the verified address owns, cause VERIFICATION_ADD /
     // VERIFICATION_REMOVE. The hook is STRUCTURALLY unable to fail, alter, or panic the merge:
     // every error warns and yields fewer hints, and the merge result + trie are untouched.
@@ -5037,7 +5037,7 @@ mod tests {
             test_helper::commit_block_events(engine, vec![&block_event]).await;
         }
 
-        // Register `channel_key` to `owner` via the increment-7 block-event fold path (populates
+        // Register `channel_key` to `owner` via the channel-register block-event fold path (populates
         // the shard's own ByOwnerAddress replica). REGISTER hint fires as a side effect.
         async fn register_channel(engine: &mut ShardEngine, channel_key: &str, owner: Vec<u8>) {
             let event = events_factory::create_channel_register_event(