Fix release signing and unify "+" upload with the share-intent path

- Release builds now sign with a dedicated keystore (local
  android/key.properties or CI secrets, both gitignored) instead of each
  machine's own debug key, so a downloaded release APK can actually
  update a previous install instead of failing with "App not installed"
  (mismatched signature).
- The Files tab's "+" -> "Upload File" now goes through the same
  ShareUploadView destination picker and background foreground-service
  upload as receiving a file via Android's "Share to..." sheet, instead
  of a separate blocking in-app-only upload path. Removed the
  now-unused ServerProvider/NextcloudService.uploadFileFromPath.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.claude/context/architecture.md

@@ -118,7 +118,12 @@ owns the app's share-intent listener (`ShareIntentService`, backed by
 hand-rolled native handling in `MainActivity.kt` - see `server.md` for why
 this isn't the `receive_sharing_intent` plugin): both `getInitialShare()`
 (cold start via another app's "Share to...") and `onNewShare` (already
-running) push `ShareUploadView`. It similarly owns the pick-intent listener
+running) push `ShareUploadView`. `FilesView`'s own "+" → "Upload File"
+(`_pickAndUploadFile`) reaches the exact same `ShareUploadView` screen
+through the same `SharedFileRef`-based path (wrapping `file_picker`'s
+result `Uri`s instead of a share intent's) rather than a separate
+in-app-only upload, so both entry points get the same destination picker
+and the same durable background-service upload. It similarly owns the pick-intent listener
 (`PickIntentService` - see `server.md` for the full "being picked by
 another app" story) that feeds `ServerProvider.pickRequest`; while
 `isPicking`, the visible tab list is overridden to just Files and Photos

.claude/context/standards.md

@@ -84,13 +84,19 @@ adb install -r build/app/outputs/flutter-apk/app-release.apk
 ```
 
 This only preserves data if the new APK's signature matches what's already
-on the device — a local build's release variant currently reuses the debug
-signing config (`android/app/build.gradle.kts`), so consecutive local
-builds share a key and `adb install -r` works cleanly. Installing a build
-signed with a different key (e.g. a CI-signed release APK from the Gitea
-release pipeline) over a differently-signed local build forces Android to
-require a full uninstall regardless of the install method used — there's no
-way around that from the tooling side.
+on the device. `android/app/build.gradle.kts` picks a release signing key
+in this order: a local `android/key.properties` (gitignored — points at a
+gitignored keystore file, e.g. `android/app/release-keystore.jks`), then
+CI env vars (`RELEASE_KEYSTORE_PATH`/`_PASSWORD`, `RELEASE_KEY_ALIAS`/
+`_PASSWORD`, set by `.gitea/workflows/build.yml` from repo secrets), then
+falls back to the debug key if neither is configured. As long as the same
+dedicated release keystore backs both `key.properties` locally and the
+Gitea secrets, local release builds and CI-built release APKs share one
+signature, so `adb install -r` works cleanly either way. A local checkout
+with no `key.properties` set up falls back to the (per-machine, ungitted)
+debug key, which won't match a CI-signed APK — installing one over the
+other still forces a full uninstall, since there's no way around Android's
+signature check from the tooling side.
 
 ## Dependencies