Please address the comments from this code review:

## Overall Comments
- The docstring for `get_full_tool_set` still describes a simple "last one wins" behavior, but with the new `add_tool` logic the actual rule is "prefer active tools, otherwise last one wins"; consider updating the docstring to accurately reflect this to avoid confusion for future maintainers.
- The interaction between `FuncToolManager.func_list` ordering, `get_func`, and `ToolSet.add_tool` now encodes fairly subtle precedence rules (active vs inactive, built-in vs MCP, earlier vs later); it may help to centralize this resolution logic in a small helper or make the precedence rules more explicit in comments to reduce the risk of regressions if `add_tool` is changed later.

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="astrbot/core/provider/func_tool_manager.py" line_range="314-315" />
<code_context>

     def get_func(self, name) -> FuncTool | None:
-        for f in self.func_list:
+        # 优先返回已激活的工具（后加载的覆盖前面的，与 ToolSet.add_tool 保持一致）
+        for f in reversed(self.func_list):
+            if f.name == name and getattr(f, "active", False):
+                return f
</code_context>
<issue_to_address>
**issue (bug_risk):** Align default `active` handling between `get_func` and `ToolSet.add_tool` to avoid inconsistent behavior.

Here `getattr(f, "active", False)` treats tools without an `active` attribute as inactive, while `ToolSet.add_tool` uses `getattr(..., True)`, treating them as active in conflict resolution. This mismatch means a tool can be active in the set but skipped by `get_func` when a same-name tool has `active=False`. Please align the default in both places and adjust comments/behavior so conflict resolution and lookup remain consistent.
</issue_to_address>

### Comment 2
<location path="tests/unit/test_tool_conflict_resolution.py" line_range="44-52" />
<code_context>
+        assert len(toolset.tools) == 1
+        assert toolset.tools[0].active is True
+
+    def test_both_active_last_one_wins(self):
+        """When both tools are active, the new one should overwrite."""
+        toolset = ToolSet()
+        toolset.add_tool(make_tool("web_search", active=True))
+        toolset.add_tool(make_tool("web_search", active=True))
+
+        assert len(toolset.tools) == 1
+        # The second tool should be the one kept
+        assert toolset.tools[0].description == "Test tool web_search"
+
+    def test_both_inactive_last_one_wins(self):
</code_context>
<issue_to_address>
**issue (testing):** This test does not actually prove that the second active tool is the one kept.

Because both tools are created identically, this assertion would still pass if the first tool were kept. To really validate the overwrite behavior, differentiate the two instances and assert that the second is the one retained, for example:

```python
first = make_tool("web_search", active=True)
second = make_tool("web_search", active=True)
second.description = "Second web search"

toolset = ToolSet()
toolset.add_tool(first)
toolset.add_tool(second)

assert len(toolset.tools) == 1
assert toolset.tools[0] is second
assert toolset.tools[0].description == "Second web search"
```

This will fail if the implementation keeps the first tool instead of the last.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `FunctionToolManager.get_func`, you can avoid iterating `func_list` twice by doing a single reverse pass that tracks the last-seen tool and immediately returns on the first active match, falling back to the last-seen match if none are active, which keeps the same semantics with simpler and slightly more efficient logic.