Add maxRetries option to Meteor.apply

[mark1russell7]

Summary

Adds a maxRetries option to Meteor.apply / applyAsync: the maximum number of times an already-sent method may be re-sent when a dropped connection is recovered. Once exceeded, the method fails with the same invocation-failed error that noRetry produces (maxRetries: 0 is equivalent to noRetry). Unset preserves Meteor's default retry-forever behavior.

This is the maxRetries feature split out of #10 as a minimal, refactor-free change. The ExecutionGroup refactor from #10 will be proposed separately.

Why

Between noRetry (fail on first reconnect) and the default (re-send forever), there is no way to say "this method is worth retrying a few times, but must not outlive N reconnects." Unbounded re-send is a liability for non-idempotent methods on flapping connections; maxRetries bounds it.

Design notes

• Implemented on the existing MethodInvoker — no scheduling changes. MethodInvoker.consumeRetry() owns the budget; the existing noRetry filter in _handleOutstandingMethodsOnReset is its single call site, so noRetry and maxRetries share one code path and one failure shape.
• Fails with invocation-failed (not disconnected) so error handling written for noRetry applies unchanged. disconnected remains the signal for "connection permanently down" (see Fix DDP method hang on disconnect and null socket in Session.close() meteor/meteor#14193); invocation-failed means "connection recovered, but this call gave up."

Tests

• maxRetries: 2 — re-sent on reconnects 1 and 2 (same method id), fails with invocation-failed on the 3rd; _methodInvokers and _outstandingMethodBlocks fully cleaned up
• maxRetries: 0 — never re-sent, fails on the first reconnect (same behavior and error code as noRetry)
• unset — re-sent on every reconnect (5 cycles), callback never fires