arch(mobile): discuss nullability of selectedProject in useProjectStore

[masch]

Context

Currently, selectedProject in useProjectStore is typed as Project | null, defaulting to null on application start. This forces consumer utilities (like date/time validators and moment expirations) to use optional chaining (?.) and fallback timezones.

An alternative design is to initialize selectedProject to getDefaultProject() and keep it non-nullable (Project), avoiding optional chaining and fallback variables.

Pros & Cons of the Current Design (Nullable Project | null)

Pros:

• Explicit Loading & Selection State: Clearly distinguishes when a project has not yet been fetched from the API or selected by the user. Allows components (like the tourist portal) to display loaders or selectors.
• Accurate Domain Model: Reflects reality; a project is indeed absent until initialized.

Cons:

• Optional Chaining Boilerplate: Forces every pure consumer utility to use ?. and define defaults/fallbacks (e.g. timezone fallbacks).
• Potential Null Reference Issues: Higher risk of runtime null checks in code where we assume a project is already loaded.

---

Pros & Cons of the Alternative Design (Non-Nullable Project / Initialized to Default)

Pros:

• Simplified Client Logic: Utilities can access selectedProject.zzz_timezone directly without ?. or fallback operators.
• Null Safety: Prevents null pointer exceptions entirely for this state.

Cons:

• False State Initialization: Initializing to a default project mock before fetching from the API might cause flashing UI or mask fetching bugs (e.g., rendering screen data with El Impenetrable mocks before Ibera project is loaded from the backend).
• Refactoring Overhead: Requires rewriting several components (e.g., apps/mobile/src/app/tourist/index.tsx) and unit tests that expect null to trigger initial fetching.

---

Next Steps

Discuss if it's worth making selectedProject non-nullable, possibly by introducing a separate isInitialized boolean flag to track loading state, or if keeping it nullable with utility fallbacks is the preferred pattern.