minSplt issue, and a suggestion

I want to start by thanking you all for your work developing and maintaining TITAN2. I am covering it in my graduate level course in applied multivariate statistics this quarter, and my preparations for this have led to a question and a suggestion.

The `minSplt` argument has a default of 5, which I interpret to mean that each split should create a group of five or greater. This means that the smallest value of the environmental variable to be considered should be larger than the fifth smallest value in the set, and the largest value to be considered should be smaller than the fifth largest value in the set. However, **this is not applied consistently to the two ends of a dataset**.
For example, consider the sample glades data:
```
data(glades.env)
data(glades.taxa)
glades.titan <- titan(glades.env, glades.taxa)
```

The object `glades.titan$env` contains the full set of environmental variables (126 in this case), the object `glades.titan$srtEnv` contains these values in sorted order from smallest to largest, and the object `glades.titan$envcls` contains a subset of the sorted variables (117 in this case). The `envcls` object is `srtEnv` adjusted by `minSplt` – this is shown on line 140 of the GitHub code for `control.functions.R`:
`envcls <- srtEnv[(minSplt):(numUnit - minSplt)]`

However, this coding only drops the four smallest values have been omitted. **I believe this should be modified to**:
`envcls <- srtEnv[(minSplt + 1):(numUnit - minSplt)]`

This leads to my suggestion. The `srtEnv` object includes multiple repeated values (6.5, 7.8, 9.6, etc). **Why not focus on the unique values in this set?** This would require a bit more nuance when applying apply `minSplt` – in this case, the five smallest values are only three unique values (2.5, 3.3, 3.5) – but would be more computationally efficient because duplicate values would only be evaluated once. In the current analysis, focusing on unique values would reduce the number of candidate change points by 14% (from 117 to 101):
```
glades.titan$envcls |> length()
glades.titan$ envcls |> unique() |> length()
```

Having duplicate candidate change points in the set defined by `srtEnv` also leads me to wonder how duplicate permutations and bootstraps for the same candidate change point are evaluated.

Thanks for any insights you can provide!

Start in control.functions.R around line 140 and reproduce the glades.env/glades.taxa example described in the issue. Compare srtEnv and envcls at the minSplt boundaries, then trace how candidate change points feed permutation and bootstrap evaluation. Done means the boundary behavior is corrected or clarified and the handling of duplicate candidate values is resolved with corresponding verification.

Written by the indexing model from the issue text.