docs: remove unnecessary documentation for core concept

Author: abyss-s

apps/landing/src/app/(detail)/docs/core-concepts/no-dependencies/page.mdx

@@ -48,14 +48,9 @@ Our approach is grounded in static analysis. Once code is built and shipped, it
 - Class names never start with a digit (to satisfy CSS constraints).
 - We minimize class name length while maintaining safety.
   For example, tokens like `ad` may be flagged by content blockers; we emit `a-d` instead to break filter matches.
-- To avoid common ad-blocker heuristics (e.g., EasyList-style rules), we segment suspicious tokens by inserting a hyphen while keeping names compact.
+- To avoid common ad-blocker heuristics, we segment suspicious tokens by inserting a hyphen(`-`).
 - Example mappings:
   - `ad` → `a-d`
-  - `ads` → `a-ds`
-  - `adbanner` → `a-dbanner`
-  - `ad_top` → `a-d_top`
-- Generation is deterministic: the same input always yields the same safe class name across builds.
-- The policy does not depend on any specific filter list and typically remains robust as lists evolve.
 - Scope: applied to Devup UI–generated atomic class tokens only; user-supplied `className` strings are not rewritten.
 - Allowed characters include `a`–`z`, combinations like `az`, `a0`, and safe hyphen/underscore placements.
 

apps/landing/src/app/(detail)/docs/core-concepts/style-storage/page.mdx

@@ -16,7 +16,6 @@ This document explains the de-duplication principle, the requirement for a singl
 
 - Even if the same style appears in multiple places, it is generated as exactly one atomic class (no duplicates).
 - If a style already exists in storage, the existing class is reused. Otherwise, a new class is generated and registered.
-- This happens at build time (when the bundler runs). The generation order can vary depending on the order in which the input code is discovered and analyzed.
 
 ### Why a single storage is required