Exercise 1: Why Mobile & Browsers Chose an Embedded Database — Possible Solution
====================================================================

THE ARCHITECTURAL REASON, PER THIS CHAPTER
------------------------------
Per this chapter, "sqlite1-1's own embedded, no-server model is
exactly what a mobile app or a browser tab needs — there's no
possibility of running a separate database server process on a phone
or inside a browser process, so an embeddable, in-process library is
close to the only architecturally sensible choice for this entire
category of application."

CONNECTING THIS TO SQLITE1-1'S OWN MATERIAL
------------------------------
Per sqlite1-1, "MySQL and Postgres exist to let many separate
applications or processes, potentially on different machines, share
reliable, concurrent access to the same data over a network," and
require "a separate server process runs continuously, listening on a
network port." A phone's own local app storage, or a browser's own
local history/cookie storage, has no equivalent "separate server"
concept available to it at all — there's no sensible way for a phone
to be running a permanently-listening MySQL or Postgres server process
in the background just to store one app's own local notes, or a
browser's own local history. Mobile operating systems and browsers are
built around a fundamentally different deployment reality: a single
application (or a single browser process) needing its own private,
local, structured storage, with no other client ever expected to
connect to it over a network at all.

WHY SQLITE'S OWN MODEL FITS THIS EXACTLY
------------------------------
Per sqlite1-1, SQLite "is a C library, linked directly into the
application's own process," requiring no server, no network
connection, and no separate process to manage. This maps precisely
onto what a mobile app or a browser actually needs: a way to get real,
structured, reliable storage embedded directly inside the SAME process
already running the app itself, with zero additional infrastructure.
Since there's fundamentally no other client that will ever need
networked access to, say, one specific app's own private local
database, none of MySQL/Postgres's own client-server machinery
(network listening, authentication, connection pooling) provides any
value in this context — it would only add overhead and complexity
that the actual use case has no need for.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects sqlite1-1's own stated purpose of client-server databases
(many networked clients) against the mobile/browser reality (one
private, local application needing storage), and explains precisely
why SQLite's own embedded model is the architecturally sensible fit
rather than simply asserting it is.