[Deprecation] `Resolvable#limit` Compatibility Bridge for `timeout`

[silug]

Summary

LegacyFacter::Core::Resolvable uses limit as a compatibility bridge around the timeout attribute due to historical naming conflict concerns. This appears to be a legacy behavior candidate for phased deprecation.

Why This Is Soft / Inferred

No explicit @deprecated tag exists for limit, but comments and tests indicate it is retained for historical compatibility rather than as an intentional modern API.

Evidence

• lib/facter/custom_facts/core/resolvable.rb:25 comment explains #limit exists to avoid #timeout conflicts.
• lib/facter/custom_facts/core/resolvable.rb:27 defines def limit returning @timeout || 0.
• lib/facter/custom_facts/core/resolvable.rb:77 uses Timeout.timeout(limit).
• spec/custom_facts/core/resolvable_spec.rb:64 has explicit test: uses #limit instead of #timeout.

Proposed Plan

• Next major release:
  • Keep limit behavior for compatibility.
  • Add explicit deprecation warning for direct limit usage (if practical), or mark as deprecated in API docs and changelog.
  • Document preferred timeout usage.
• Subsequent major release:
  • Remove limit compatibility path (or make it private/internal-only if removal is too risky).

Compatibility / Risk

• Low to medium risk in next major release (warning/docs only).
• Medium risk in removal release if external custom facts call limit directly.

Implementation Notes

• Re-validate whether original Ruby timeout naming conflict still matters in current supported Ruby.
• If practical, emit warning in limit method to surface external usage.
• If warning cannot cleanly distinguish internal from external calls, document deprecation first and rely on major-release removal for enforcement.

Acceptance Criteria

• Next major release documents limit as deprecated compatibility behavior.
• If feasible, next major release emits deprecation warning for direct limit usage.
• Removal/privatization target is scheduled for next major release.

Follow-up Removal Issue

• Track final API decision (remove vs internal-only) for next major.

Suggested Tests

• Existing timeout behavior tests remain green in next major release.
• If warnings are added, add tests for warning emission and non-duplication behavior.

[silug]

Code in question was introduced in 757b458.