embed_docsite: download docsite via git clone instead of GitHub contents API

[IZO-Ong]

Short Description

Replaces embed_docsite's recursive GitHub Contents API walk with a shallow, blobless and sparse git clone of OpenFn/docs.

Fixes #182

Implementation Details

The old github_utils.py fetched general_docs/adaptor_docs one directory at a time via api.github.com/.../contents/{path} (~22 requests for OpenFn/docs, against a 60/hour unauthenticated limit), then downloaded each file individually. This PR ships two commits 4315b60 (for naive git clone --depth 1) and 4508e30 (for a more optimized git clone using --filter=blob:none --sparse, checked out to only docs/ and adaptors/, thus avoiding downloading static assets and images).

adaptor_functions is untouched.

New module services/embed_docsite/docs_repo.py holds all git/filesystem access behind one subprocess seam (_run_git) for unit-testing. sync_docs_repo() clones on the first call in a process and fetch+reset --hards on every call after. If a refresh fails and a checkout already exists, the existing copy is served and a warning is logged; the run only fails if there's no checkout to fall back on, similar to latest_adaptors.py's cache.

Measurements

Variant	Cold	Warm	Disk	Docs	GitHub REST calls
main (current)	102.9s	n/a (no cache)	0	191	~44/run
Trees + ETag cache (PR #618)	92.1s	1.02s	~3MB + manifest	191	2/run
Naive git clone --depth 1 (commit 1)	11.94s	2.23s	274MB	191	0
Blobless sparse clone (commit 2)	4.01s	1.27s	2.9MB	191	0

The sparse clone's corpus was verified byte-identical to the naive clone's by hashing the full get_docs output (sha256 of sorted-key JSON).

Next steps

If the optimized, blobless / sparse git clone is ok, we can change the command for dockerfile on line 17 to use the optimized version instead.

AI Usage

Please disclose whether you've used AI in this work (it's cool, we just want to
know!):

• Yes, I have used AI
• No, I have not used AI

You can read more details in our
Responsible AI Policy