Fix read-only /app failure + add app icon

On first launch O3DE pip-installs its 'o3de' CLI with 'pip install -e'
(editable), which writes an egg-info next to the source under read-only
/app and fails ([Errno 30] Read-only file system), leaving the venv broken
("unable to install O3DE's built-in Python").

- Patch cmake/LYPython.cmake at build time to force a normal (non-editable)
  install, which builds in a temp dir and lands in the writable ~/.o3de venv.
- Drop the build-time get_python "bake": the venv is per-user (keyed to
  $HOME), so it can only be created at runtime; baking under a throwaway
  build HOME did nothing. Speeds up CI; removes cmake/python3 build deps and
  the network build-arg.
- Add a real launcher icon (org.o3de.O3DE.png).

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

README.md

@@ -127,18 +127,23 @@ These were confirmed by inspecting the v26.05 package (`opt/O3DE/26.05/…`):
   engine compiles project code at runtime. Those live in the SDK. Users therefore
   pull the SDK runtime (larger than Platform) on install — Flatpak does this
   automatically from Flathub.
-- **Python is baked in at build time.** O3DE normally downloads its Python runtime
-  into its own install tree on first use, but that tree is read-only inside a
-  Flatpak. The manifest runs `python/get_python.sh` during the build (with network
-  access) so Python is part of the immutable image. **This is the most likely step
-  to need tweaking** — verify it on the first real CI build.
-- **Runtime writes into the install tree may still fail.** Anything O3DE tries to
-  `pip install` or generate *inside* `/opt/O3DE/...` at runtime (e.g. per-gem
-  Python deps when building certain projects) will hit the read-only `/app`. Base
-  project building should work; exotic gems may not. This is the main open risk.
-- **No launcher icon yet.** The `.deb` ships only in-editor asset icons, so the
-  desktop entry uses a generic icon. Drop a real O3DE logo into the repo and
-  install it in the manifest to fix this.
+- **Python is per-user, not baked in.** On first launch O3DE downloads its Python
+  runtime and builds a venv under `~/.o3de` (writable), pip-installing its deps
+  there. The build does **not** bundle Python — the venv is keyed to the user's
+  home path, so it can only be created at runtime.
+- **The editable-install patch.** O3DE installs its own `o3de` CLI with
+  `pip install -e`, which writes an `egg-info` next to the source under read-only
+  `/app` and fails. The build patches `cmake/LYPython.cmake` to use a normal
+  (non-editable) install, which builds in a temp dir and lands in the `~/.o3de`
+  venv. If a future O3DE release renames that variable, the build prints a warning
+  and Python setup will fail at runtime — that's the line to re-check.
+- **Other runtime writes into the install tree may still fail.** Anything else
+  O3DE tries to generate *inside* `/opt/O3DE/...` at runtime (e.g. certain per-gem
+  Python deps, or the engine-level asset cache) hits the read-only `/app`. Project
+  data lives in your writable home dir, so normal project work should be fine;
+  this is the main remaining open risk.
+- **Launcher icon** is shipped as `org.o3de.O3DE.png` (the `.deb` itself contains
+  only in-editor asset icons, none suitable as an app icon).
 - **GPU / drivers:** the renderer needs working GPU access. The manifest grants
   `--device=dri`/`--device=all`; on some setups you may also want the matching
   GPU driver extension from Flathub.