autoloop: support static loop-ins

[starius]

This adds static-address-backed loop-ins to the current autoloop engine.

What changes

• Liquidity params now include an explicit loop-in source, so operators can choose wallet-funded loop-ins or static-address-backed loop-ins.
• The static-address subsystem now exposes an autoloop preparation helper that selects deposits, quotes the swap, and returns a ready-to-dispatch static loop-in request.
• The liquidity planner can now produce static_loop_in suggestions, include them in forceautoloop, and enforce MaxAutoInFlight across all suggested swap types.
• Persisted static loop-ins now count in budget accounting, in-flight accounting, and peer traffic backoff.
• SuggestSwaps now exposes static loop-in suggestions through a dedicated RPC field and includes the static no-candidate disqualification reason.
• The missing public mapping for AUTO_REASON_CUSTOM_CHANNEL_DATA is added, so custom asset channels are reported as disqualified instead of breaking the RPC response.
• Static loop-in label validation now happens at the external RPC boundary, while internal autoloop dispatch can still use reserved autoloop labels.

Important design choices

• This is intentionally a narrow first step: static autoloop uses full deposits only.
• No partial static loop-ins are attempted, so no change output is created.
• Static autoloop always uses fast=false.
• There is no silent fallback from static-address loop-ins to wallet-funded loop-ins.
• If a peer deficit can only be satisfied by a partial static loop-in, the planner returns no static candidate for that peer.
• Static loop-ins are returned separately from legacy loop_in suggestions.
• Failed static loop-ins are still accounted pessimistically because exact realized static swap cost is not persisted yet.
• The main planner still excludes channels with custom channel data; this series just makes that exclusion visible and safe at the RPC layer.

Validation

• Unit coverage was added for loop-in source params, static autoloop preparation, no-change deposit selection, static fee/weight helpers, accounting with persisted static loop-ins, RPC encoding, and planner behavior.
• The feature was also validated end to end in regtest: a confirmed 1,000,000 sat static deposit was suggested through suggestswaps, dispatched through forceautoloop, completed successfully, moved the deposit to LOOPED_IN, increased outbound liquidity on the target BTC peer, and was not suggested again afterward.

Pull Request Checklist

• Update release_notes.md if your PR contains major features, breaking changes or bugfixes

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces support for static-address-backed loop-ins within the existing autoloop engine. It enables operators to utilize static deposits for automated liquidity management, providing a more flexible alternative to traditional wallet-funded loop-ins. The changes include updates to the liquidity planner, budget accounting, and RPC interfaces to ensure static loop-ins are treated as first-class citizens in the autoloop lifecycle while maintaining safety and consistency.

Highlights

• Static-Address Loop-In Support: Added support for static-address-backed loop-ins in the autoloop engine, allowing operators to choose between wallet-funded and static-address-backed sources.
• Liquidity Planner Enhancements: The liquidity planner can now suggest static loop-ins, include them in autoloop dispatch, and enforce 'MaxAutoInFlight' limits across all swap types.
• Budget and Traffic Accounting: Persisted static loop-ins are now correctly accounted for in budget limits, in-flight swap counts, and peer traffic backoff calculations.
• RPC and API Updates: Exposed static loop-in suggestions via a new RPC field and added validation for static loop-in labels at the RPC boundary.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces support for static-address loop-in swaps within the autoloop planner. It adds a new configuration option to select the loop-in source, updates the liquidity manager to handle static loop-in snapshots for budget and traffic accounting, and includes necessary changes to the RPC interface and storage layer to support these swaps. I have no feedback to provide.