:lang rust +tree-sitter: rustic-beginning-of-function fails with void-function rust-in-str-or-cmnt

### What happened?

In a Rust buffer, calling `rustic-beginning-of-function` errors with:

```elisp
Symbol’s function definition is void: rust-in-str-or-cmnt
```

### Expected behavior

`rustic-beginning-of-function` should move to the beginning of the current Rust function without error.

### Steps to reproduce

1. Enable Rust with tree-sitter:

```elisp
:lang
(rust +lsp +tree-sitter)
```

2. Open a Rust buffer using `rustic-mode`.
3. Call `M-x rustic-beginning-of-function`.

### Why it seems to happen

`rustic-beginning-of-function` calls `rustic-beginning-of-defun`, which calls `rust-in-str-or-cmnt`:

```elisp
;; rustic-interaction.el
(rust-in-str-or-cmnt)
```

That helper is defined by classic `rust-mode` in `rust-prog-mode.el`:

```elisp
(defun rust-in-str-or-cmnt () (nth 8 (syntax-ppss)))
```

But with Doom's Rust tree-sitter path, `rust-mode-treesitter-derive` makes `rust-mode` derive from Emacs' built-in `rust-ts-mode`, so `rust-prog-mode.el` is not loaded. `rustic` still assumes the classic helper exists, so the function is void.

### Local workaround

This fixes it locally:

```elisp
(after! rustic-interaction
(unless (fboundp 'rust-in-str-or-cmnt)
(defun rust-in-str-or-cmnt () (nth 8 (syntax-ppss)))))
```

### Possible fix

Doom could provide this compatibility shim when `:lang rust +tree-sitter` and `rustic` are used together, or avoid the `rustic` path that depends on classic `rust-mode` internals.

### Versions

```text
GNU Emacs 31.1
Doom modules commit: d57ab52a3
rustic commit: 4afbca4
rust-mode commit: 0058837
```

Start by reading rustic-interaction.el around rustic-beginning-of-defun and rust-prog-mode.el for rust-in-str-or-cmnt. Reproduce M-x rustic-beginning-of-function with :lang rust +tree-sitter and rustic enabled, then verify the command reaches the beginning of the current Rust function without the void-function error.

Written by the indexing model from the issue text.