Be more pedantically correct in offer/refund builder documentation

Instead of making vague reference to "those docs", indicate exactly
which docs we're suggesting the user go hunt for. Also, for variant
methods, just say "see the original method for more details" rather
than trying to spell out all the things that exist in the
documentation for the other method. This avoids things getting
stale and doesn't reduce the information users have.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -11554,6 +11554,9 @@ macro_rules! create_offer_builder { ($self: ident, $builder: ty) => {
 	///
 	/// # Privacy
 	///
+	/// Uses [`MessageRouter`] provided at construction to construct a [`BlindedMessagePath`] for
+	/// the offer. See the documentation of the selected [`MessageRouter`] for details on how it
+	/// selects blinded paths including privacy implications and reliability tradeoffs.
 	/// Uses the [`MessageRouter`] provided to the [`ChannelManager`] at construction to build a
 	/// [`BlindedMessagePath`] for the offer. See those docs for privacy implications.
 	///
@@ -11584,7 +11587,7 @@ macro_rules! create_offer_builder { ($self: ident, $builder: ty) => {
 	/// This gives users full control over how the [`BlindedMessagePath`] is constructed,
 	/// including the option to omit it entirely.
 	///
-	/// See [`Self::create_offer_builder`] for details on offer construction, privacy, and limitations.
+	/// See [`Self::create_offer_builder`] for more details on usage.
 	///
 	/// [`BlindedMessagePath`]: crate::blinded_path::message::BlindedMessagePath
 	/// [`Offer`]: crate::offers::offer::Offer
@@ -11627,9 +11630,9 @@ macro_rules! create_refund_builder { ($self: ident, $builder: ty) => {
 	///
 	/// # Privacy
 	///
-	/// Uses [`MessageRouter`] to construct a [`BlindedMessagePath`] for the refund based on the given
-	/// `absolute_expiry` according to [`MAX_SHORT_LIVED_RELATIVE_EXPIRY`]. See those docs for
-	/// privacy implications.
+	/// Uses [`MessageRouter`] provided at construction to construct a [`BlindedMessagePath`] for
+	/// the refund. See the documentation of the selected [`MessageRouter`] for details on how it
+	/// selects blinded paths including privacy implications and reliability tradeoffs.
 	///
 	/// Also, uses a derived payer id in the refund for payer privacy.
 	///
@@ -11676,12 +11679,7 @@ macro_rules! create_refund_builder { ($self: ident, $builder: ty) => {
 	/// refund, including the option to omit it entirely. This is useful for testing or when
 	/// alternative privacy strategies are needed.
 	///
-	/// See [`Self::create_refund_builder`] for:
-	/// - refund recognition by [`ChannelManager`] via [`Bolt12Invoice`] handling,
-	/// - `payment_id` rules and expiration behavior,
-	/// - invoice revocation and refund failure handling,
-	/// - defaulting behavior for `max_total_routing_fee_msat`,
-	/// - and detailed payment and privacy semantics.
+	/// See [`Self::create_refund_builder`] for more details on usage.
 	///
 	/// # Errors
 	///

lightning/src/offers/flow.rs

@@ -562,8 +562,9 @@ where
 	///
 	/// # Privacy
 	///
-	/// Uses the [`OffersMessageFlow`]'s [`MessageRouter`] to construct a [`BlindedMessagePath`]
-	/// for the offer. See those docs for privacy implications.
+	/// Uses [`MessageRouter`] provided at construction to construct a [`BlindedMessagePath`] for
+	/// the offer. See the documentation of the selected [`MessageRouter`] for details on how it
+	/// selects blinded paths including privacy implications and reliability tradeoffs.
 	///
 	/// Also uses a derived signing pubkey in the offer for recipient privacy.
 	///
@@ -598,7 +599,7 @@ where
 	/// This gives users full control over how the [`BlindedMessagePath`] is constructed,
 	/// including the option to omit it entirely.
 	///
-	/// See [`Self::create_offer_builder`] for details on offer construction, privacy, and limitations.
+	/// See [`Self::create_offer_builder`] for more details on usage.
 	pub fn create_offer_builder_using_router<ME: Deref, ES: Deref>(
 		&self, router: ME, entropy_source: ES, peers: Vec<MessageForwardNode>,
 	) -> Result<OfferBuilder<DerivedMetadata, secp256k1::All>, Bolt12SemanticError>
@@ -682,8 +683,9 @@ where
 	///
 	/// # Privacy
 	///
-	/// Uses the [`OffersMessageFlow`]'s [`MessageRouter`] to construct a [`BlindedMessagePath`]
-	/// for the offer. See those docs for privacy implications.
+	/// Uses [`MessageRouter`] provided at construction to construct a [`BlindedMessagePath`] for
+	/// the refund. See the documentation of the selected [`MessageRouter`] for details on how it
+	/// selects blinded paths including privacy implications and reliability tradeoffs.
 	///
 	/// The builder will have the provided expiration set. Any changes to the expiration on the
 	/// returned builder will not be honored by [`OffersMessageFlow`]. For non-`std`, the highest seen
@@ -734,11 +736,7 @@ where
 	/// This gives users full control over how the [`BlindedMessagePath`] is constructed,
 	/// including the option to omit it entirely.
 	///
-	/// See [`Self::create_refund_builder`] for:
-	/// - how the resulting [`Refund`] is recognized by [`OffersMessageFlow`] and verified via [`Self::verify_bolt12_invoice`],
-	/// - refund expiration handling,
-	/// - rules around revocation and [`Event::PaymentFailed`] behavior,
-	/// - and defaulting logic for `max_total_routing_fee_msat`.
+	/// See [`Self::create_refund_builder`] for more details on usage.
 	///
 	/// # Errors
 	///