Feature/we 2376 migrate lido UI to monorepo structure

[cakeinpanic]

Migration to monorepo structure based on RFC

Currenlty storybook deployment on preview stand contains only dummy html while this task is pending devops attention. But this is not a blocker for this PR merge since preview stands are only used during PR review, deployment of prodution-storybook is github pages-based

There are just two things that can only be verified after merging to main — the prod Storybook deploy and the prod libs deploy — but I don't expect any surprises there. 🤞

Alpha versions released are an equal replacement for actual versions of packages:

Comparison: lido-ui@4.0.0-alpha.121 vs lido-landing-ui@1.0.0-alpha.2 (+ lido-shared-ui@1.0.0-alpha.2)
lido-landing-ui extracts theme/cookie code (theme-css/, utils/) out into @lidofinance/lido-shared-ui and re-exports it; all other components are unchanged. Verified:

Exports match 1:1 — all 20 symbols lido-ui exported directly (ContentTheme, ThemeProvider, ThemeToggler, useThemeToggle, ThemeName, themeCookieKey, CookieThemeProvider, modalRoot, getTopLevelDomain, cookie helpers, VOID_FN, etc.) are present and re-exported from lido-shared-ui.
Tabs.js is byte-identical between the two (modulo a comment-punctuation nit).
Cookie/theme logic (cookie-theme-provider.js, theme-provider.js, use-theme-toggle.js, element-theme-script.js, utils/cookies.js, secure-cookie logic, themeCookieKey value) is byte-identical or logically equivalent (minor refactors only: get-top-level-domain.js ternary rewrite, modalRoot.js catch-binding style, ua-parser-js/classnames bundled vs required — no behavior change, and the bundled ua-parser-js version matches the declared 2.0.3 dependency, so no version drift).
ThemeToggler renders a native <button> element in lido-shared-ui instead of the shared Button component (shape="circle" size="s") that lido-ui uses. Confirmed this component is only referenced in Storybook — not consumed by any app-facing code — so the markup swap has no production blast radius.
Verdict: Safe to treat lido-landing-ui@1.0.0-alpha.2 + lido-shared-ui@1.0.0-alpha.2 as a drop-in replacement for the equivalent lido-ui@4.0.0-alpha.121 surface.

@lidofinance/lido-ui@3.43.0-alpha.1 vs @lidofinance/lido-ui@3.42.2
Runtime code is identical — all compiled .js files (component logic) are byte-for-byte the same. Differences found are all non-functional:

.d.ts type declarations differ: TypeScript version/strictness change — 3.42.2 emits foo?: T | undefined, alpha emits foo?: T (same meaning, different strict config), and alpha drops a stray /// <reference types="react" />.
package.json metadata is very different: alpha.1 is type: "module" with dist/esm/index.mjs, built via rollup + tsc, tested with vitest; 3.42.2 is CJS-primary, built via a custom zx script, tested with jest. This is dev-tooling/monorepo-migration fallout, not a runtime change.
LICENSE.txt and README.md are missing from the 3.43.0-alpha.1 tarball (present in 3.42.2).
All .js.map sourcemap files differ (expected — different build paths/tooling).
Verdict: functionally identical, but the alpha's package is missing LICENSE/README, and its build/publish config has shifted to ESM+rollup+vitest as part of the monorepo migration.

[preview-stands]

Preview stand status

Stand was demolished

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.