A first-class neural leaf, so "mixed neuro-symbolic computation" survives the model boundary

The README says, in the "In a nutshell" list:

> - Support for mixed, neuro-symbolic computation.

The mechanism behind that today is `FunctionModel` — a `LeafModel` holding a `FunctionWrapper` and an
`info::NamedTuple` (`src/utils/models/leaf.jl:155`). A neural network wrapped that way **composes**
correctly, which is real and useful. But it arrives as an opaque callable: the architecture, the
parameters, and the framework it came from are all gone by the time the model is a leaf. Nothing
downstream can tell one wrapped network from another, export it, hash it, or verify it.

That is fine for "call this function"; it is not enough for a package whose purpose is transparent
modelling. This issue proposes closing the distance between the claim and the representation.

## The proposal

A **first-class neural leaf** — name yours, `NeuralModel` is a placeholder — that is still a
`LeafModel` and still composes exactly as `FunctionModel` does, but additionally carries the identity
of what it wraps: framework and version, an architecture description, and a content hash of the
parameters. Optionally, an export to a portable format (ONNX being the obvious one).

Nothing about existing behaviour changes. `FunctionModel` stays; this is the case where the caller
knows more than "it is a function" and wants that preserved.

### Where it should live, and why not a new package

`Project.toml` already declares:

```toml
[weakdeps]
DecisionTree = "7806a523-6efd-50cb-b5f6-3fa6f1930dbb"
XGBoost = "009559a3-9522-5dbb-924b-0b6ed2b22bb9"

[extensions]
DecisionTreeExt = "DecisionTree"
XGBoostExt = "XGBoost"
```

So the pattern for an optional heavy learned-model backend already exists here, twice. A `FluxExt`
sits beside those with zero load cost when Flux is absent, no new registry entry, no second CI, and no
extra compat matrix to maintain. A separate package would duplicate a pattern this one already runs,
and would still need the abstract type here anyway — otherwise every downstream package must depend on
it merely to talk about a model.

Hence: **the type in `SoleModels`, the framework bindings in extensions.**

## Why a Concept Bottleneck Model is the right first instance

Not because CBMs are fashionable, but because a CBM is already shaped like a Sole model: a neural
concept predictor feeding a symbolic head — input → named concepts → a usually linear or sparse
predictor → label. It is not a neural model this package must learn to tolerate; it is a neural leaf
feeding a model this package already represents. It is arguably the cleanest possible instance of the
neuro-symbolic claim the README already makes.

It also makes downstream rule extraction *well-posed*. `SolePostHoc`'s REFNE samples uniformly inside a
per-feature min/max box and labels each sample with the model. In raw input space that is statistically
hopeless — high dimension, samples off the data manifold. Over a concept bottleneck it is a few dozen
named, bounded dimensions, which is the regime that method was designed for. And the existing
`SoleData.ScalarCondition` machinery over named scalar features already speaks the concept layer's
language, so much of it should work as-is.

A search for "concept" across `SoleModels`, `SolePostHoc`, `SoleData` and `SoleXplorer` returns
nothing, so this is greenfield rather than a second implementation of something already here.

## What I am not proposing

- No change to `FunctionModel` or to any existing signature.
- No hard dependency on Flux, ONNX, or anything else, in the core package.
- No training code. This is about *representing* a trained network, not producing one.
- No claim that a neural leaf becomes interpretable by being wrapped. It becomes **identifiable**,
which is the precondition for everything else — extraction, verification, audit — and not a
substitute for any of them.

## Where this comes from

We contribute to this ecosystem from outside and have been working through
[SoleLogics #109](https://github.com/aclai-lab/SoleLogics.jl/issues/109)/#111 and
[SoleReasoners #14](https://github.com/aclai-lab/SoleReasoners.jl/issues/14) recently. This one is
larger and touches your architecture, so it is a proposal rather than a pull request: **your naming and
your layering win**, and if you would rather this lived elsewhere or took a different shape, say so and
we will follow that instead.

Happy to implement whichever version you settle on.