fix/deprecated-lfs-flags

[bwalsh]

Deprecate lfs.SyntheticOIDFromETag and lfs.WriteAddURLSentinelObject

Summary

Deprecate sentinel-based add-url object identity helpers:

• lfs.SyntheticOIDFromETag
• lfs.WriteAddURLSentinelObject

These functions currently support unknown-SHA add-url flows by creating synthetic OIDs and sentinel payloads in local object storage.

Motivation

The sentinel path introduces non-authoritative object identity and additional complexity in push/pull behavior. We should converge on explicit, authoritative object identity and simplify add-url object lifecycle handling.

Current behavior

• lfs.SyntheticOIDFromETag derives synthetic OID from ETag.
• lfs.WriteAddURLSentinelObject writes sentinel bytes under local object storage.
• Unknown-SHA add-url workflows depend on this path.

Proposed change

1. Mark both functions deprecated in code comments and internal call sites.
2. Introduce a replacement flow for unknown-SHA add-url that does not rely on sentinel payloads.
3. Add migration guards to prevent regressions in existing repositories.
4. Remove deprecated APIs in a follow-up major/minor compatibility window (TBD by maintainers).

Scope

• internal/lfs/sentinel.go
• cmd/addurl/* call sites
• any push/pull logic that checks sentinel object content
• docs that describe unknown-SHA sentinel mode

Acceptance criteria

• lfs.SyntheticOIDFromETag has Deprecated: godoc notice.
• lfs.WriteAddURLSentinelObject has Deprecated: godoc notice.
• New add-url unknown-SHA path exists and is covered by tests.
• Existing repositories with sentinel objects continue to function during transition.
• Docs updated with migration guidance and timeline.

Testing

• Unit tests for unknown-SHA add-url replacement path.
• Backward-compat test that reads existing sentinel objects without hard failure.
• Push/pull integration tests for mixed old/new metadata states.

Open questions

• What compatibility window do we want before full removal?
• Should sentinel parsing remain read-only for one release after write-path deprecation?

[matthewpeterkort]

addressed in #232