Should `acap-build` file handling quirks

I found these quirks (bugs? - up to you) while fuzzing my own implementation of an acap build tool. None of them seem to enable an app to misbehave once installed on the device.

### Describe the bug

> [!IMPORTANT]
> Disclaimer: I used generative AI to help me word this and write the reproducers.
> I have reviewed all the output and I have verified the two first quirks myself.

#### 1. `--additional-file` breaks on names containing whitespace

`package.conf` stores additional files in a single, space-separated
`OTHERFILES` variable, which `eap-create.sh` expands **unquoted** into `tar`
(line 98) and into its validation loop (`for _file in $OTHERFILES`, line 459).
So `acap-build --additional-file 'a b.txt' ./` word-splits `a b.txt` into two
operands, `a` and `b.txt`:

#### 2. 255-byte EAP-name truncation can split a UTF-8 character

This guard seems to have been added to avoid a papercut of similar to the kind
reported here (the comment right above it reads `# Avoid too long tar file
names`).

`friendlyName` may be non-ASCII and up to 256 characters (schema-valid), so its
UTF-8 encoding can exceed the 255-byte cap on the `.eap` file name. The cap is
enforced with `cut -b` (bytes), so truncation can land mid-character and produce
an invalid-UTF-8 EAP file name — and a matching, equally mangled `…_LICENSE.txt`.

AI says, though I haven't verified this:

> Separately, the length *check* one line above uses `${#package_name}`
> (characters, since the script runs under `bash` in a UTF-8 locale) while the
> *cut* uses bytes, so a name that is ≤ 237 characters but > 255 bytes skips
> truncation entirely — defeating the very cap it's meant to enforce.
> (`eap-create.sh`, lines ~74–77.)

#### 3. `--additional-file` matching an `--exclude` pattern is silently dropped

`eap-create.sh` always passes `--exclude-vcs --exclude="*~"` to `tar`, and GNU
`tar` applies `--exclude` patterns to operands too, not just to files reached by
recursing into directories. So an additional file whose name matches a pattern
(e.g. a backup file `notes~`, or a VCS file like `.gitignore`) is silently
dropped even though it exists: `tar` exits 0 with no warning (had the file been
missing it would instead fail with `Cannot stat`). `acap-build` still writes
`OTHERFILES="notes~"` into `package.conf`, so `package.conf` ends up referencing
a file that is absent from the archive, and the build reports success.

### To reproduce

Please see the GitHub actions workflow in https://github.com/apljungquist/acap-build-bug-candidates

Start with eap-create.sh around lines 74–77, 98, and 459, then use the linked GitHub Actions workflow to reproduce the three reported cases. Check how whitespace, UTF-8 names, and tar exclusions affect the archive and package.conf; done means additional files are preserved and referenced consistently with valid EAP filenames.

Written by the indexing model from the issue text.