Feature: profile-level override for rclone Google Drive default OAuth client

[CruxExperts]

Summary

Add an explicit snapshot-profile option that allows a Google Drive rclone remote to use rclone's default/shared Drive OAuth client when the operator has intentionally chosen to reuse an existing machine-level rclone synchronization setup.

Problem

bbackup currently treats any Google Drive rclone: snapshot profile without a configured client_id as unhealthy:

Google Drive remote ALIEN001-GD has no client_id; configure a dedicated OAuth client before treating this snapshot profile as reliable

That is a good safe default, but it blocks hosts where the same rclone remote is already the configured and monitored Google Drive synchronization surface. On SCAR01, the mounted Google Drive service and the backup profile both use the same working remote:

ALIEN001-GD:

The remote is reachable, mounted, and has a valid token, but no dedicated client_id field. Because the health check is hard-fail only, local snapshot automation refuses to run with:

Refusing to run snapshot profile with critical alerts

Requested behavior

Keep the current safety default, but add an explicit profile-level opt-in such as:

snapshot_profiles:
  essentials-daily:
    repository: rclone:ALIEN001-GD:backups/SCAR01/restic/essentials-daily
    allow_default_rclone_drive_client: true

When this flag is absent or false, preserve the current behavior: Google Drive remotes without client_id fail health checks.

When true, allow the profile health check to pass with a clear message such as:

Google Drive remote ALIEN001-GD uses the default rclone Drive client by explicit profile configuration

Local proof-of-concept

A focused local patch was tested with:

uv run pytest tests/test_snapshot.py -q

Result:

16 passed

The patch shape is small:

• Add SnapshotProfile.allow_default_rclone_drive_client: bool = False.
• Parse allow_default_rclone_drive_client from profile config.
• In _rclone_drive_client_id_check, accept a Drive remote without client_id only when the profile flag is true.
• Add a regression test proving default rejection remains and explicit opt-in passes.

Rationale

This keeps the conservative default for reliability-sensitive backups while giving operators an auditable way to acknowledge and accept the existing rclone Drive client configuration for a specific profile. The opt-in is profile-local, visible in config review, and avoids weakening health checks globally.

[CruxExperts]

Additional finding from validating the local workaround: there is a second snapshot-run blocker in repo reconciliation.

Path-reuse false positive on normal repo updates

reconcile_repos() currently treats any same-path fingerprint change as path_reuse_conflict. Because _repo_from_path() includes HEAD in the fingerprint, normal commits in an active repository can change the fingerprint and make snapshot runs fail with critical alerts such as:

Refusing to run snapshot profile with critical alerts

The alert messages look like this even when the repo path was not retired and reused:

Retired repo path reused with a different Git fingerprint: /mnt/data/devzone/bbackup
Retired repo path reused with a different Git fingerprint: /home/cptnfren/myrig

Suggested fix shape

• Keep head as tracked metadata, but do not include it in the stable repository fingerprint.
• Only raise path_reuse_conflict against retired entries at the same path.
• For active entries at the same path, update the existing state row in place.
• Add a regression test that commits a new change to an active repo and verifies reconcile_repos() returns no alerts and preserves the active repo id.

Local focused tests after adding this regression plus the Drive-client override test:

uv run pytest tests/test_snapshot.py -q
17 passed

[CruxExperts]

Implemented in PR #5: #5

What changed for this issue:

• allow_default_rclone_drive_client is parsed conservatively: only YAML boolean true enables the opt-in; quoted strings such as "false" do not.
• Google Drive rclone remotes without client_id remain rejected by default.
• The explicit opt-in now applies to profile health and is enforced before non-dry snapshot init, snapshot run, snapshot check, and snapshot restore operations.
• Docs and config examples include the cautionary profile-local setting.
• The related active-repo fingerprint false positive is fixed by removing HEAD from the stable fingerprint, preserving legacy state safely, and blocking unknown same-path identity conflicts.

Validation evidence:

• uv run python scripts/check_version_sync.py -> ok
• uv run python scripts/check_publishing_ready.py -> ok
• uv run python -m py_compile bbackup.py bbman.py bbackup/*.py bbackup/data/*.py bbackup/management/*.py scripts/*.py -> ok
• git diff --check -> ok
• env HOME=/tmp/bbackup-codex-home uv run pytest tests/test_snapshot.py -q -> 23 passed
• env HOME=/tmp/bbackup-codex-home uv run pytest tests/ -m "not integration" -q -> passed
• env HOME=/tmp/bbackup-codex-home uv run pytest tests/integration/test_snapshot_restic.py -q -> passed
• systemd-analyze verify on rendered snapshot services/timers -> passed

I am leaving this issue open until PR #5 is merged so the fix is durably available on the target branch.

[CruxExperts]

Closed by merged PR #5 and shipped in v1.8.5: https://github.com/CruxExperts/best-backup/releases/tag/v1.8.5

Release validation passed in GitHub Actions, including lint/syntax, unit tests across Python 3.12/3.13/3.14, integration tests, release build, wheel smoke test, and GitHub release publication with wheel and sdist assets.