fix: stabilize incremental inference and index ownership

.agents/skills/rust-best-practices/references/chapter_01.md

@@ -2,7 +2,7 @@
 
 ## 1.1 Borrowing Over Cloning
 
-Rust's ownership system encourages **borrow** (`&T`) instead of **cloning** (`T.clone()`). 
+Rust's ownership system encourages **borrow** (`&T`) instead of **cloning** (`T.clone()`).
 > ❗ Performance recommendation
 
 ### ✅ When to `Clone`:
@@ -361,7 +361,7 @@ Well-written Rust code, with expressive types and good naming, often speaks for
 
 Still, there are **moments where code alone isn't enough** - when there are performance quirks, external constraints, or non-obvious tradeoffs that require a nudge to the reader. In those cases, a concise comment can prevent hours of head-scratching or searching git history.
 
-### ✅ Good comments 
+### ✅ Good comments
 
 * Safety concerns:
 ```rust
@@ -398,8 +398,8 @@ let subgraph_tls_root_store: RootCertStore = configuration
 
 * Wall-of-text explanations: long comments and multiline comments
 ```rust
-// Lorem Ipsum is simply dummy text of the printing and typesetting industry. 
-// Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, 
+// Lorem Ipsum is simply dummy text of the printing and typesetting industry.
+// Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
 // when an unknown printer took a galley
 fn do_something_odd() {
     …
@@ -480,7 +480,7 @@ There are a few gotchas when calling comments "living documentation":
 * Many large comments make people avoid reading them.
 * Team becomes fearful of delete irrelevant comments.
 
-If you find a comment, **don't trust it blindly**. Read it in context. If it's wrong or outdated, fix or remove it. A misleading comment is worse than no comments at all. 
+If you find a comment, **don't trust it blindly**. Read it in context. If it's wrong or outdated, fix or remove it. A misleading comment is worse than no comments at all.
 
 > Comments should bother you - they demand re-verification, just like stale tests.
 

.agents/skills/rust-best-practices/references/chapter_02.md

@@ -34,7 +34,7 @@ Potential additions elements to add:
 
 > Example at ApolloGraphQL
 >
-> In the `Router` project there is a `xtask` configured for linting that can be executed with `cargo xtask lint`. 
+> In the `Router` project there is a `xtask` configured for linting that can be executed with `cargo xtask lint`.
 
 ## 2.3 Important Clippy Lints to Respect
 
@@ -69,7 +69,7 @@ enum Message {
 ```
 
 > The fix would be:
-> 
+>
 > ```rust
 > // Faster matching is preferred over size efficiency
 > #[expect(clippy::large_enum_variant)]

.agents/skills/rust-best-practices/references/chapter_03.md

@@ -169,7 +169,7 @@ hello_greet(Cow::Owned("Naomi".to_string()));
 
 ## 3.3 Stack vs Heap: Be size-smart!
 
-### ✅ Good Practices 
+### ✅ Good Practices
 
 * Keep small types (`impl Copy`, `usize`, `bool`, etc) **on the stack**.
 * Avoid passing huge types (`> 512 bytes`) by value or transferring ownership. Prefer pass by reference (e.g. `&T` and `&mut T`).

.agents/skills/rust-best-practices/references/chapter_05.md

@@ -14,12 +14,12 @@ In Rust, as in many other languages, tests often show how the functions are mean
 > In the unit test name we should see the following:
 > * `unit_of_work`: which *function* we are calling. The **action** that will be executed. This is often be the name of the the test `mod` where the function is being tested.
 ```rust
-#[cfg(test)] 
-mod test { 
-    mod function_name { 
-        #[test] 
-        fn returns_y_when_x() { ... } 
-    } 
+#[cfg(test)]
+mod test {
+    mod function_name {
+        #[test]
+        fn returns_y_when_x() { ... }
+    }
 }
 ```
 > * `expected_behavior`: the set of **assertions** that we need to verify that the test works.
@@ -83,9 +83,9 @@ mod test { // IDEs will provide a ▶️ button here
             let a = setup_a_to_be_xyz();
             let b = Some(-5);
             let expected = MyError::Xyz;
-            
+
             let result = process(a, b).unwrap_err();
-            
+
             assert_eq!(result, expected);
         }
 
@@ -124,8 +124,8 @@ mod test_thing_parser {
     fn lowercase_letters_are_valid() {
         assert!(
             Thing::parse("abcd").is_ok(),
-            // Works like `eprintln, format and println` macros 
-            "Thing parse error: {:?}", 
+            // Works like `eprintln, format and println` macros
+            "Thing parse error: {:?}",
             Thing::parse("abcd").unwrap_err()
         );
     }
@@ -141,7 +141,7 @@ mod test_thing_parser {
 
 ### Use very few, ideally one, assertion per test
 
-When there are multiple assertions per test, it's both harder to understand the intended behavior and 
+When there are multiple assertions per test, it's both harder to understand the intended behavior and
 often requires many iterations to fix a broken test, as you work through assertions one by one.
 
 ❌ Don't include many assertions in one test:
@@ -185,19 +185,19 @@ We will deep dive into docs at a later stage, so in this section we will just br
 
 ```rust
 /// Helper function that adds any two numeric values together.
-/// This functions reasons about which would be the correct type to parse based on the type 
+/// This functions reasons about which would be the correct type to parse based on the type
 /// and the size of the numeric value.
-/// 
+///
 /// # Examples
-/// 
+///
 /// ```rust
 /// # use crate_name::generic_add;
 /// use num::numeric;
-/// 
+///
 /// # assert_eq!(
 /// generic_add(5.2, 4) // => 9.2
 /// # , 9.2)
-/// 
+///
 /// # assert_eq!(
 /// generic_add(2, 2.0) // => 4
 /// # , 4)
@@ -243,7 +243,7 @@ mod unit_of_work_tests {
 
 ### Integration Tests
 
-Tests that go under the `tests/` directory, they are entirely external to your library and use the same code as any other code would use, not have access to private and crate level functions, which means they can **only test** functions on your **public API**. 
+Tests that go under the `tests/` directory, they are entirely external to your library and use the same code as any other code would use, not have access to private and crate level functions, which means they can **only test** functions on your **public API**.
 
 > Their purpose is to test whether many parts of the code work together correctly, units of code that work correctly on their own could have problems when integrated.
 
@@ -252,14 +252,14 @@ Tests that go under the `tests/` directory, they are entirely external to your l
 * if testing binaries, try to break **executable** and **functions** into `src/main.rs` and `src/lib.rs`, respectively.
 
 ```
-├── Cargo.lock 
-├── Cargo.toml 
-├── src 
-│   └── lib.rs 
-└── tests 
-    ├── mod.rs 
-    ├── common 
-    │   └── mod.rs 
+├── Cargo.lock
+├── Cargo.toml
+├── src
+│   └── lib.rs
+└── tests
+    ├── mod.rs
+    ├── common
+    │   └── mod.rs
     └── integration_test.rs
 ```
 
@@ -341,7 +341,7 @@ Snapshot testing compares your output (text, Json, HTML, YAML, etc) against a sa
 assert_snapshot!("this_is_a_named_snapshot", output);
 ```
 
-* Keep snapshots small and clear. 
+* Keep snapshots small and clear.
 ```rust
 // ✅ Best case:
 assert_snapshot!("app_config/http", whole_app_config.http);
@@ -350,7 +350,7 @@ assert_snapshot!("app_config/http", whole_app_config.http);
 assert_snapshot!("app_config", whole_app_config); // Huge object
 ```
 
-> #### 🚨 Avoid snapshotting huge objects 
+> #### 🚨 Avoid snapshotting huge objects
 > Huge objects become hard to review and reason about.
 
 * Avoid snapshotting simple types (primitives, flat enums, small structs):

.agents/skills/rust-best-practices/references/chapter_07.md

@@ -1,6 +1,6 @@
 # Chapter 7 - Type State Pattern
 
-Models state at compile time, preventing bugs by making illegal states unrepresentable. It takes advantage of the Rust generics and type system to create sub-types that can only be reached if a certain condition is achieved, making some operations illegal at compile time. 
+Models state at compile time, preventing bugs by making illegal states unrepresentable. It takes advantage of the Rust generics and type system to create sub-types that can only be reached if a certain condition is achieved, making some operations illegal at compile time.
 
 > Recently it became the standard design pattern of Rust programming. However, it is not exclusive to Rust, as it is achievable and has inspired other languages to do the same [swift](https://swiftology.io/articles/typestate/) and [typescript](https://catchts.com/type-state).
 
@@ -141,8 +141,8 @@ impl Builder<MissingName, AgeSet> {
 
 impl Builder<NameSet, AgeSet> {
     fn build(self) -> Person {
-        Person { 
-            name: self.name.unwrap_or_else(|| unreachable!("Name is guarantee to be set")), 
+        Person {
+            name: self.name.unwrap_or_else(|| unreachable!("Name is guarantee to be set")),
             age: self.age,
             email: self.email,
         }

.agents/skills/rust-best-practices/references/chapter_08.md

@@ -127,7 +127,7 @@ Use `///` doc comments to document:
 
 ```rust
 /// Loads [`User`] profile from disk
-/// 
+///
 /// # Error
 /// - Returns [`MyError`] if the file is missing [`MyError::FileNotFound`].
 /// - Returns [`MyError`] if the content is an invalid Json, [`MyError::InvalidJson`].
@@ -139,9 +139,9 @@ fn load_user(path: &Path) -> Result<User, MyError> {...}
 ```rust
 /// Returns the square of the integer part of any number.
 /// Square is limited to `u128`.
-/// 
+///
 /// # Examples
-/// 
+///
 /// ```rust
 /// assert_eq!(square(4.3), 16)
 /// ```
@@ -203,9 +203,9 @@ pub fn add(a: i32, b: i32) -> i32 {
 Use `//!` when you want to document the **purpose of a module or a crate**. It is places at the top of a `lib.rs` or `mod.rs` file, for example `engine/mod.rs`:
 ```rust
 //! This module implements a custom chess engine.
-//! 
+//!
 //! It handles board state, move generation and check detection.
-//! 
+//!
 //! # Example
 //! ```
 //! let board = chess::engine::Board::default();

.agents/skills/rust-best-practices/references/chapter_09.md

@@ -2,7 +2,7 @@
 
 Many higher level languages hide memory management, typically **passing by value** (copy data) or **passing by reference** (reference to shared data) without worrying about allocation, heap, stack, ownership and lifetimes, it is all delegated to the garbage collector or VM. Here is a comparison on this topic between a few languages:
 
-### 📌 Language Comparison 
+### 📌 Language Comparison
 
 | Language | Value Types | Reference/Pointer Types | Async Model & Types | Manual Memory |
 |------------ |------------------------------------- |----------------------------------------------------------- |---------------------------------------------------------------------------- |------------------------------ |
@@ -178,7 +178,7 @@ use std::{cell::OnceCell, rc::Rc};
 #[derive(Debug, Default)]
 struct MyStruct {
     distance: usize,
-    root: Option<Rc<OnceCell<MyStruct>>>, 
+    root: Option<Rc<OnceCell<MyStruct>>>,
 }
 
 fn main() {