Testing and Finishing the Missing Steps of the Pay Plugin

# Background

Recent versions of Core Lightning have encountered some issues with the `pay` command (see [issue #7219](https://github.com/ElementsProject/lightning/issues/7219)), prompting many projects to rewrite it. [Ocean](https://ocean.xyz/) has taken a different approach by restricting the amount of gossip a node processes, which can significantly improve payment reliability.

However, Core Lightning’s payment strategy is still under development, and we currently lack a comprehensive framework for implementing new routing strategies. While this is no longer entirely true thanks to `xpay` and `askrene`, which are being introduced in the upcoming release, these tools are just starting to provide solutions.

This limitation restricts what can be achieved with a vanilla Core Lightning node without risking issues in production. Ocean plans to deploy an experimental node alongside its stable one to explore new operational strategies. It would be great to have a plugin capable of working alongside `xpay` and the native `pay` command of Core Lightning to facilitate comparisons.

**P.S.:** This plugin uses LDK under the hood.

# Goal

The goal of this project is to complete the remaining steps to integrate LDK (via [`LDKRoutingStrategy`](https://github.com/coffee-tools/barq/blob/main/barq-common/src/algorithms/probabilistic/mod.rs#L127)) and rapid gossip sync into the plugin.

Key steps include:
- Explore the plugin implementation, starting with [`plugin::main`](https://github.com/coffee-tools/barq/blob/main/barq-plugin/src/main.rs), and learn how to work with a Core Lightning plugin.
- Set up a Core Lightning node on testnet or signet. If you want to avoid downloading the entire blockchain, consider using [Folgore](https://github.com/coffee-tools/folgore). Test `barq` by making payments as demonstrated in my lessons.
- Address the remaining tasks for the plugin:
- Implement persistent scoring (see [Lampo](https://github.com/vincenzopalazzo/lampo.rs) for guidance on making scoring data persistent). Refer to the code at [`probabilistic/mod.rs#L155`](https://github.com/coffee-tools/barq/blob/main/barq-common/src/algorithms/probabilistic/mod.rs#L155).
- Ensure full support for Bolt11 invoices, focusing on public info parts. If it doesn’t work, write tests to confirm your findings ([test_simple.py](https://github.com/coffee-tools/barq/blob/main/tests/test_simple.py)).
- Add support for Bolt12 within the LDK/probabilistic implementation. Although this isn’t currently covered, the integration should be straightforward.
- Submit your solution via a PR with a clean git history to facilitate a thorough review. Without this, your PR might not receive the necessary attention.

## Notes

If you’ve made friends during the class and want to work in a group, this project is not a toy. Collaborating in teams of 2–3 people is encouraged.

---

This is a project for [PlanB.network](https://planb.network).

Start with plugin::main in barq-plugin/src/main.rs and the probabilistic implementation around probabilistic/mod.rs#L155. Set up a testnet or signet Core Lightning node, then run tests/test_simple.py while testing payments. Done means persistent scoring, verified Bolt11 public-info handling with tests, and Bolt12 support in the LDK/probabilistic integration.

Written by the indexing model from the issue text.