feat(mobile): replace SAP landing screen with Android notes app

[devxvoid]

Motivation

• Provide a focused Android-ready notes screen in the mobile app as requested by replacing the SAP WebView landing/demo surface.
• Prefer a simple, local-first example that demonstrates UI, persistence, and basic list interactions for mobile development and testing.
• Remove reliance on the complex SAP RFUI injection flow from the default root screen so the app can be used independently.

Description

• Replaced the SAP-focused root screen implementation with a notes app at artifacts/mobile/app/index.tsx that implements a header, multiline input, add button, note cards, delete action, and empty state.
• Added local persistence using AsyncStorage under the key notes-app-v1 to load notes on startup and save on changes, including defensive handling of invalid stored payloads.
• Implemented note metadata with generated IDs and createdAt timestamps, a note counter label derived from notes.length, and a styled FlatList rendering.
• Removed the WebView + SAP inspection/injection code and the SAP-specific UI/logic from the replaced file and simplified styles to match the new notes UI.

Testing

• Ran type checking with pnpm --filter @workspace/mobile typecheck, which exited with errors; the reported TypeScript syntax errors are located in artifacts/mobile/app/warehouse.tsx and are pre-existing and unrelated to the notes screen change.
• No additional automated tests were added or run for the new UI beyond the TypeScript typecheck.

---

Codex Task

---

^{Need help on this PR? Tag @codesmith with what you need.}

• Let Codesmith autofix CI failures and bot reviews

[gemini-code-assist]

Code Review

This pull request replaces the complex SAP WMS mobile application with a simplified notes application that uses AsyncStorage for local persistence. The review feedback identifies a critical race condition in the persistence logic where the initial empty state could overwrite existing data before the loading process completes. Additionally, there is a recommendation to optimize date formatting within the list's render function to prevent performance issues and ensure consistent behavior across different mobile JavaScript engines.

[gemini-code-assist]

There is a race condition in the persistence logic. The useEffect responsible for saving notes (lines 40-42) runs on the initial render because notes is initialized to an empty array. Since AsyncStorage operations are asynchronous, this effect might overwrite existing stored notes with an empty array before the loading effect (lines 27-38) completes. I recommend adding an initialization flag to ensure that saving only occurs after the initial data has been loaded.

  const [notes, setNotes] = useState<Note[]>([]);
  const [inputValue, setInputValue] = useState("");
  const [isInitialized, setIsInitialized] = useState(false);

  useEffect(() => {
    void (async () => {
      try {
        const raw = await AsyncStorage.getItem(STORAGE_KEY);
        if (raw) {
          const parsed = JSON.parse(raw) as Note[];
          setNotes(parsed);
        }
      } catch {
        await AsyncStorage.removeItem(STORAGE_KEY);
      } finally {
        setIsInitialized(true);
      }
    })();
  }, []);

  useEffect(() => {
    if (isInitialized) {
      void AsyncStorage.setItem(STORAGE_KEY, JSON.stringify(notes));
    }
  }, [notes, isInitialized]);

[gemini-code-assist]

Calling new Date().toLocaleString() inside renderItem can lead to performance issues as the list grows and may produce inconsistent results across different JavaScript engines (e.g., JSC vs Hermes on Android). It is better to format the date once when the note is created or use a memoized component for the list items.