Add Z3R4H rebrand: Windows launcher, .exe wrapper, geo services, modes, prompts and UI integration

[RadDad87]

Motivation

• Pivot the product to a Windows-first, fully-offline local UX under the Z3R4H brand with an emphasis on local llama.cpp inference and offline hardening.
• Provide a simple operator entrypoint (portable launch_z3r4h.bat) and a staged .exe wrapper scaffold to enable an exe-first RC path while preserving a BAT fallback.
• Add on-device geo/terrain capabilities and UI surfaces to support a new "Navigation & Terrain" mode and related survival workflows.

Description

• Rebranded core app strings and manifests to Z3R4H and updated constants (APP_NAME, web manifests, app.html, notifications, etc.).
• Added Windows-local launcher launch_z3r4h.bat with localhost-only checks, offline defaults, port preflight, readiness probes, logging to z3r4h_launcher.log, and mode-specific Open WebUI start handling.
• Implemented an initial native .exe wrapper scaffold under wrapper/ (C#/.NET) that resolves package root, validates config, orchestrates dual-service startup (llama + Open WebUI), offers readiness probes, structured exit codes, and BAT fallback invocation.
• Introduced full geo service stack under backend/open_webui/services/geo/ including valhalla_client, DEM loader, terrain analysis, suitability scoring, AI orchestration, schemas, router (/api/geo), and config flags for offline data; wired router in backend/open_webui/main.py.
• Added frontend Z3R4H features: prompt stack and mode prompts (src/lib/prompts/z3r4h), prompt composition utility composeZ3R4HPromptStack, mode routing resolveZ3R4HRoutedModelId, mode selector component Z3R4HModeSelector.svelte, mode binding in chat flow, and a new maps route/UI (/maps) with GeoAdvisor and result cards.
• Updated numerous files to integrate the prompt-stack and mode routing into the chat send path, preserved deterministic routing fallback behaviour, and added portable package layout/docs (PROJECT_BRIEF.md, TASKS.md, Z3R4H_CLEAN_ENV_CHECKLIST.md, Z3R4H_PROGRESS_SUMMARY.md).
• Added tests and lightweight contract checks: backend geo pytest tests, frontend vitest UI contract tests, and wrapper contract checks under wrapper/tests.

Testing

• Ran backend geo unit/integration tests with pytest in backend/open_webui/test/geo/test_geo_endpoints_and_services.py, which exercise /api/geo endpoints, DEM fallback logic, suitability scoring, and intent classification; tests executed and passed.
• Executed frontend contract tests with vitest in src/lib/components/map/__tests__/maps_flow.spec.ts to validate maps UI hooks and loading/error states; tests executed and passed.
• Executed wrapper contract checks in wrapper/tests/test_wrapper_startup_contract.py to validate presence of orchestration stages and fallback messaging in the wrapper scaffold; tests executed and passed.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0df8fe23fc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Treat non-2xx readiness responses as not ready

The readiness probe currently marks an endpoint as ready for any HTTP status < 500, so a misconfigured health URL returning 404 or an auth-protected endpoint returning 401/403 is treated as success. In WaitForEndpointReadyAsync, that can let startup continue (and even skip fallback paths) before AI/backend/routing is actually healthy, causing the launcher to report success while the product is unusable.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Use computed sample distance for slope analysis

This route path computes terrain slopes using compute_slope_profile(metrics['elevations_m']), which falls back to the default 30m spacing, but extract_route_metrics already calculates per-route sample_distance_m from decoded geometry. Ignoring that value skews slope, difficulty, and risk outputs for routes whose point spacing is far from 30m, producing systematically inaccurate terrain advice.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Validate site-search center inputs before ranking

SiteSearchRequest allows both coordinates and route_area to be omitted, but this handler does not validate that at least one is present before calling find_*. In that case _resolve_center raises ValueError, which is uncaught here and becomes a 500 response instead of a client error, so malformed user input triggers server errors.

Useful? React with 👍 / 👎.