docs: add docs/ARCHITECTURE.md and explain the scar tissue in client.ts

[Waynting]

Second of the two PRs for #49, and the half you said deserves more
discussion. Independent of #52 — either can land first, though #52's intro
references this file by name.

Split by distance exactly as you framed it: the document carries what someone
needs before opening a file, the comments carry what is only understandable
at the line.

docs/ARCHITECTURE.md

Leads with the premise rather than a module tour, because every other decision
in client.ts is downstream of it: there is no public Overleaf API, so the
client authenticates as a logged-in browser session and calls the endpoints the
web editor's own JavaScript calls. Cookie plus scraped CSRF token, meta-tag
parsing, Socket.IO for the file tree, and the write endpoints — none of it
versioned or documented, which is what makes the fallbacks meaningful instead
of merely cautious.

Two things I gave more room than the issue proposed, because they were the
things I got wrong reading the code cold:

uploadFile overwrites, it does not edit. The web editor sends
character-level operations over the collaboration socket; the upload endpoint
replaces a whole file. I assumed push merged in some fashion until I read it
properly. Stating it explains push having no merge semantics and diff
existing at all, so it is in the document and on the function.

The module map is framed as "does this need an account". That is the
question that decides where new logic goes, and the pure/impure split is
already the repository's answer — scan.ts, rename-plan.ts and diff.ts
each exist because of it. Worth stating rather than leaving to be inferred.

Also a short "when Overleaf breaks it" section: --verbose first, then the
meta tag, then suspect the socket, keep old fallbacks for self-hosted.

The comments in client.ts

Four places. The first is a correction rather than an addition:

The file header claimed to provide "programmatic access to Overleaf's REST
APIs". That is precisely the misconception the document exists to correct,
sitting at the top of the file someone opens first.

extractCsrfToken and listProjects each had numbered fallbacks with
nothing saying they are successive Overleaf redesigns. Your "scar tissue"
phrase is the right one, and I added the part that makes it actionable:
dropping the older branches breaks self-hosted instances without breaking
overleaf.com, so whoever tidies them away will not see the failure.

getProjectFromSocket now says what it is — a hand-written Socket.IO 0.9
client — why it exists (the tree left the meta tags and no HTTP route returns
it), and that it is the first suspect when the tree breaks.

uploadFile gets the overwrite semantics, as above.

npm run lint, npm run build and npm test pass; the only code change is
comments, so nothing behavioural moved.