feat(android): opt-in signing-URL launch strategy for presentCaptiveSigning

[IronTony]

Draft. Depends on #3 and rebases once that merges.

What this adds

An opt-in launchStrategy: 'signingUrl' on presentCaptiveSigning for Android.

The SDK's fetch-based launchCaptiveSigning downloads the envelope with include=documents before opening the ceremony. That download runs on a read timeout derived from the envelope size, which floors at 15s when nothing is cached, so a large envelope on a slow connection exhausts it and the ceremony never opens.

The SDK also exposes a signingURL overload that skips the download entirely. 'signingUrl' mints a recipient view with the session access token and points the SDK straight at it, so the call that times out never runs. Verified on device across 12 consecutive ceremonies.

Defaults to 'fetch', which is byte-identical to current behaviour, so upgrading changes nothing for existing consumers. Opt-in rather than default because the mint spends the consumer's bearer token on an endpoint that token is not guaranteed to be scoped for. A mint failure falls back to 'fetch', so the strategy can only add a way to succeed.

If your backend already mints recipient views, presentCaptiveSigningWithUrl remains the better shape since it keeps the token off the device entirely. This exists for teams who cannot change their backend.

Concurrency notes

Minting puts a network round trip between capturing the Activity and using it, which the synchronous fetch path never did. Two guards:

• canLaunchOn refuses to launch against a finishing or destroyed Activity, and checks the pending completion by identity, not nullness. reset() and endSigningSession() clear that slot, and a fresh presentCaptiveSigning can claim it while a mint is still in flight. A nullness check would pass in that window and launch this envelope wired to the new session's promise, resolving it with the wrong outcome.
• Session credentials moved into a single DocuSignSession reference rather than three independent @Volatile fields, so a login racing an in-flight mint cannot tear the triple and build a request with one session's token and another's account id.

Known trade-off: the mint thread holds the Activity reference for the round trip. Timeouts are set to 15s (rather than the 30s this was first written with) to bound that, and canLaunchOn prevents any use of a dead Activity, but the reference is retained for the duration regardless.

After #3 merges

This PR also picks up the maintainer items I pulled off that review. All of them touch pre-existing code rather than anything nikonhub introduced, so they were never that PR's to carry:

• fold presentCaptiveSigningWithUrl into the shared launcher and extract captiveSigningListener(), so the two entrypoints stop carrying duplicate listeners
• null currentEnvelopeId in presentCaptiveSigning's catch, matching the shape feat: add Android support for captive signing with URL #3 got right
• drop the duplicate emitSigningError in both flows, so recipient_signing_failed stops flattening into signing_failed
• forward CodedException.code instead of hard-coding signing_failed
• fill in the README Throws bullet once the error code settles

Testing

npm test: 17 passing, useDocuSignSigning.ts at 100% lines / 87% branches. Four new cases cover the passthrough, including that omitting launchStrategy produces a payload with no such key at all rather than one set to undefined, which is the backward-compat guarantee.