Fix the security audit's findings

ShareDownload::$authenticated was a public property without #[Locked],
so a visitor with a share's link but not its password could set it from
the browser and see the file list: names, folder paths, sizes and
whether the share holds a text. The contents stayed protected; the flag
is now locked, and a test tries to set it.

Sessions hold the keys of the password shares a recipient unlocked, and
were stored unencrypted in the sessions table wherever SESSION_ENCRYPT
was not set, which includes every Docker install. They are now
encrypted unless SESSION_ENCRYPT=false. Share keys never live in the
session, so every share stays readable; people sign in again once.

The container generated an APP_KEY when none was set, printed it to the
logs and generated another on the next start, which left the shares
without a password unreadable. It now refuses to start without one and
says how to create it; docker-compose.example.yml requires it for both
services. The command it names, and the README's, now pass
--entrypoint php: the image's entrypoint ignores its arguments, so
"docker run <image> php artisan key:generate --show" never ran it.

Every proxy is trusted, so the password-reset mail built its link from
a host a forged X-Forwarded-Host could choose. It is now built from
APP_URL.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -94,7 +94,7 @@ curl -O https://gitea.nonameweb.ch/noNameWEB/SealShare/raw/branch/main/docker-co
 cp docker-compose.example.yml docker-compose.yml
 
 # Generate an app key and paste it into docker-compose.yml
-docker run --rm gitea.nonameweb.ch/nonameweb/sealshare:latest php artisan key:generate --show
+docker run --rm --entrypoint php gitea.nonameweb.ch/nonameweb/sealshare:latest artisan key:generate --show
 
 # Edit docker-compose.yml — set APP_KEY and APP_URL, and choose how HTTPS is served (below)
 # Then start: