Recover orphaned Google Docs via appProperties

[llbbl]

Deferred from #5 (see PR #12).

GoogleDriveTransport.upload() calls files.create and returns the new fileId, but the consumer owns the manifest that persists it. If the process dies between the successful create and the manifest write, the Doc exists in Drive with nothing pointing at it — and the next publish creates a duplicate, forever.

Under drive.file, files.list only returns files this app created, so tagging creates with appProperties makes the orphan findable at no additional scope.

Tasks

• Set appProperties: { polydocCanonicalId: canonicalId } on files.create (and preserve it on update).
• Expose a lookup — e.g. findExistingFileId(canonicalId) — querying appProperties has {key='polydocCanonicalId' and value='...'}, usable as a resolveExistingFileId implementation.
• Decide whether lookup is opt-in or automatic on create. Automatic costs an extra API round-trip per upload; opt-in keeps the fast path fast.
• Tests with the Drive client mocked, including the duplicate-create scenario this prevents.

Also worth doing before the first npm release

Every Drive test is mocked. The review flagged files.update carrying mimeType: application/vnd.google-apps.document as the call shape most likely to behave differently against the real API. One manual smoke test against a real account: create → confirm it opens as a native Google Doc; update → confirm the content changed and the mimeType is still application/vnd.google-apps.document; confirm folderId works with a Picker-granted folder.