Add legal docs, redesign profiles and chats tab, fix fullscreen images, add code style

Signed-off-by: denis0001-dev <denis0001.dev@ya.ru>

.cursor/rules/code-style.mdc

@@ -0,0 +1,16 @@
+---
+description: Read CODE_STYLE.md before writing or refactoring Kotlin/Compose code
+alwaysApply: true
+---
+
+# Code style
+
+Before writing or editing Kotlin / Compose code in this repo:
+
+1. **Read** [`CODE_STYLE.md`](../../CODE_STYLE.md) at the repository root.
+2. **Follow** it — write idiomatic, well-structured code from the start; match neighboring files when a rule is ambiguous.
+3. **Do not ask the user style questions** when implementing new code.
+
+For style cleanup on an existing diff or file set, use the **`adapt-to-style`** skill.
+
+Build and platform rules remain in `android.mdc`.

.cursor/rules/kotlin-clean-code.mdc

@@ -1,13 +0,0 @@
----
-description: Keep Kotlin code clean — inline single-use helpers, match project conventions
-globs: app/shared/**/*.kt,utils/shared/**/*.kt
-alwaysApply: false
----
-
-# Kotlin clean code
-
-- If a function, variable, or small wrapper is used **once**, inline it at the call site unless it clarifies a non-obvious boundary (network call, animation controller, crypto).
-- Prefer existing project components (`ActionButton`, `Category`, `ExpressiveStepFlow`, `apiRequest`) over new abstractions.
-- Match surrounding naming, imports, and composable structure; read adjacent files before adding helpers.
-- Extract only when shared by **2+** call sites or when the block exceeds ~40 lines of non-trivial logic (pager math, crypto, API wiring).
-- No hardcoded user-visible strings in shared UI — use Compose Multiplatform resources (`composeResources/values/strings.xml` + `values-ru`).

.cursor/skills/adapt-to-style/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: adapt-to-style
+description: Adapts Kotlin/Compose code (diff, single file, or multiple files) to FromChat CODE_STYLE.md strictly without changing behavior. Use when cleaning up style, refactoring for conventions, adapting a diff to code style, or when the user mentions adapt-to-style, code style cleanup, or style pass.
+---
+
+# Adapt to style
+
+Refactor target code to match [`CODE_STYLE.md`](../../../CODE_STYLE.md) at the repository root. **Do not change behavior.**
+
+## Writing new code
+
+When implementing features (not a style-only pass):
+
+1. Read `CODE_STYLE.md` before writing.
+2. Follow it from the start — inline single-use bindings, idiomatic Kotlin, match neighboring files.
+3. **Do not ask the user style questions** — apply the guide and use your judgment.
+
+## Style adaptation pass
+
+When cleaning up an existing diff or file set:
+
+### Before you start
+
+1. Read `CODE_STYLE.md` fully.
+2. Identify scope: git diff, named files, or a directory.
+3. Read surrounding files in the same package for precedent.
+
+### Refactor checklist
+
+Apply in order:
+
+- [ ] **Inline** `val`/`var`/locals/`@Composable` used exactly once in the file (§1).
+- [ ] **Merge** screen-only helper files into their parent screen file (§2).
+- [ ] **Replace** non-idiomatic Kotlin with idioms: `runCatching {}`, `buildList {}`, `buildMap {}`, etc. (§3).
+- [ ] **Group** related multi-file features into sub-packages where appropriate (§4).
+- [ ] **Reuse** existing project components; remove one-off wrappers (§5).
+- [ ] **Strings** — no new hardcoded user-visible copy; use compose resources (§6).
+- [ ] **Formatting** — one blank line between composables; `private` screen helpers; no `.dp` named constants (§7).
+- [ ] **Expression bodies** where §8 applies.
+
+### Uncertainty log
+
+Only during a **style adaptation pass** — not when writing new code.
+
+When unsure how to refactor something:
+
+1. Create or append to `.cursor/code_style_progress_<YYYYMMDD-HHmm>.md` (use current local time).
+2. For each item:
+
+   ```markdown
+   ## relative/path/File.kt
+   - Unsure: [specific construct and why]
+   - Chosen approach: [what you did for now]
+   ```
+
+3. Continue refactoring — do not block on open questions.
+4. After all files are done, **re-read** the progress file and ask the user the listed questions.
+
+### Constraints
+
+- No behavior, API, or logic changes.
+- No magic-string sanitization of real user/message data.
+- Minimal diff: only what style requires.
+- Do not extract new abstractions that would be used once.
+- Do not split files that §2 says should be merged.
+- Do not change public API for style-only passes.
+
+### Validation
+
+After Android-affecting changes, run per `android.mdc`:
+
+```bash
+export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && ./gradlew :app:shared:compileAndroidMain :app:shared:compileKotlinIosArm64
+```
+
+Fix compile errors before finishing.
+
+### Output
+
+Summarize:
+
+- Files touched and main style changes.
+- Any entries from the progress file that need user decisions.
+- Build result.