proposal(near): define guard/deprecation plan for legacy finish_withdraw_v2 path

[omarespejel]

Proposal: lifecycle plan for legacy finish_withdraw_v2 (pause/deprecate/remove)

This is a proposal issue to align on lifecycle handling before implementation.

Context

finish_withdraw_v2 remains available as a legacy path and has different control behavior from primary transfer paths.

File context:

• near/omni-bridge/src/lib.rs (finish_withdraw_v2)

Proposal goal

Define a clear lifecycle and control model for this legacy method:

• keep + guard,
• deprecate over timeline,
• or remove after migration criteria.

Candidate approach

1. Short term:

• align pause/control behavior with current transfer controls
• add explicit eventing/telemetry for any legacy path usage

2. Medium term:

• define objective removal criteria (traffic threshold, migration completion)

Test expectations

• pause behavior alignment tests
• backward compatibility tests while method remains enabled
• explicit deprecation/disable tests when criteria met

Maintainer input requested

1. Is finish_withdraw_v2 still operationally required in production?
2. If yes, should it follow same pause policy as main transfer paths now?
3. What migration/removal criteria should be considered complete?

Tracked under epic: #556