batpipe: no syntax color when less opens a file by absolute path

### Summary

`batpipe` drops syntax coloring when `less` opens a file with slashes in the path, but colorizes correctly when the same file is opened by a bare relative name.

### Environment

- macOS 26.5.1
- bat-extras 2024.08.24 (Homebrew)
- less 668
- bat 0.26.1

### Steps to reproduce

With batpipe wired up as the `less` preprocessor:

Setup environment:

```sh
export LESSOPEN="|batpipe %s"
export BATPIPE=color
export LESS=-R
```

Execute:

```sh
printf 'def hi():\n return 1\n' > /tmp/file.py

less /tmp/file.py # no color
cd /tmp && less file.py # colorized
```

Using `BATPIPE_DEBUG=1` shows the difference:

```
less /tmp/file.py -> BATPIPE_INSIDE_LESS: false (slashes in path)
less file.py -> BATPIPE_INSIDE_LESS: true (bare name, run from /tmp)
```

### Cause

batpipe decides whether it is running inside `less` by taking the `basename` of its parent's **entire** `ps` command line. When `less` is invoked with a file path, that command line ends in the path, so the basename resolves to the file's name (e.g. `file.py`) instead of `less`. `BATPIPE_INSIDE_LESS` stays `false`, so batpipe never passes `--color=always` to bat.

### Fix

PR #96 already addresses this by moving the `cut -d' ' -f1` into `lib/proc.sh::parent_executable` so only the executable name is compared. I am going to open a companion PR adding a regression test for it.