Two seekers record an absolute local path in file_infos, the other three record a relative one

Two of the five seekers record an absolute path on the examiner's machine in `file_infos`, where the other three record an extraction-relative one. The value reaches the LAVA database and the report, so what an examiner sees depends on which input type was used. Opening for discussion rather than sending a PR, because the string form is a judgement call and it touches all five cores.

## What each seeker records

`FileInfo(...)` in `scripts/search_files.py`:

| Seeker | Records | Form |
|---|---|---|
| `FileSeekerZip` | `member` | extraction relative |
| `FileSeekerTar` | `member.name` | extraction relative |
| `FileSeekerItunes` | `relative_path` | extraction relative |
| `FileSeekerDir` | `item` | absolute path on the examiner's machine |
| `FileSeekerFile` | `self.single_file_abs_path` | absolute path on the examiner's machine |

iTunes is iLEAPP only. The other four are the same in all five cores.

## Measured

Same evidence file, same artifact, two runs. LAVA `_file_path_list.file_path`:

```
zip input private/var/mobile/Library/Preferences/com.apple.MobileSMS.plist
directory input /Users//extraction/private/var/mobile/Library/Preferences/com.apple.MobileSMS.plist
```

This is not a table that only sits there. `platform.electron.js` joins `_file_path_list` with `_artifact_search_patterns` and `_artifact_pattern_to_file` in `getProcessedFiles` and `getProcessedFilesCount`, so the value is shown in LAVA's processed files view. The same paths are also written into the per-regex listing on the report's `index.html`.

The intended form is stated twice already. `lava_insert_sqlite_file_path` documents its argument as "Relative file path to store", and the comment in `admin/test/scripts/test_module.py` says "In a real run, source_path is the original path in the evidence".

## Who reads it

Small and identical across the cores:

- `ilapfuncs.py`, assigns it to the media registry
- `ilapfuncs.py`, `media_id = sha1(source_path)`
- `lavafuncs.py`, two writes of the media source path
- `scripts/artifacts/messageRetention.py`, takes `os.path.basename` only, so unaffected either way
- `scripts/artifacts/discord_cache.py`, a helper named `get_rel_path` that already expects a relative value and silently returns an absolute one on directory input
- `scripts/artifacts/burnerCache.py`, fixed separately in #2056 and no longer depends on the absolute form

Nothing opens or stats the attribute, which is structurally guaranteed: zip and tar already record a bare member name, so a consumer that opened it would be broken on those inputs today.

Two things that could have blocked this do not:

- Media ids change on directory input, since they are a sha1 of this value. They do not appear in any recorded baseline. All 157 iLEAPP and 25 ALEAPP snapshots were checked; the only sha1-shaped values are an app's own recorded file hashes and a device UUID, both read out of evidence.
- `FileSeekerDir.search` already computes the relative form as `item_rel_path` two lines above the `FileInfo(item, ...)` call, and already passes it as the case-collision hash source. The value is in hand and discarded.

## What needs deciding

1. **The string form.** Zip members carry no leading slash, `private/var/...`. Matching that keeps all five seekers identical and is what #2056 assumed. The alternative is a leading slash, which reads more like a device path in a report.
2. **The single-file seeker.** With one file and no input tree there is no obvious root to be relative to. Basename, or the name it is staged under, or leave it as is.
3. **Windows long paths.** `item` can carry the `\\?\` prefix. `ileapp.py` already strips it for display; the relative computation would need the same.
4. **Whether to change it at all.** A directory input is the one case where the absolute path is real and resolvable on the examiner's machine, so there is an argument that it is useful there. The counter is that it makes the same column mean two different things depending on input type, and it publishes the examiner's directory layout.

## Validation this would need

Before and after runs on `-t fs` and `-t file` specifically. Every check behind this so far has used zip inputs, which is the reason it went unnoticed: `admin/scripts/check_report_local_paths.py` reads artifact source, and this is entry point and seeker code, so it cannot see it either.

Affects iLEAPP, ALEAPP, RLEAPP, VLEAPP and DLEAPP.