Fix FileBase upload area persistence and no-results menu handling

[Juergen-Coding]

Summary

This PR fixes two FileBase-related issues:

1. Uploads could end up in the first available file area instead of the user-selected target area.
2. The "no results" screen in FileBase could behave incorrectly and not return cleanly.

Problem 1: wrong upload target area

When uploading a file through the FileBase UI, the selected target area was not reliably preserved after returning from the protocol transfer module.

As a result, the upload handler could fall back to the first available file area instead of using the selected one.

In local testing, uploads always fell back to the first configured area (bbs) even when another area such as texte had been selected.

Root cause

The upload module lost the selected area context during the round-trip through protocol selection and file receive handling.

After returning from the transfer module, the upload workflow resumed with transferred files present, but without a valid selected area in memory, which triggered a fallback to the first available area.

Fix

core/upload.js

• removed the NoHistory behavior from the upload module
• explicitly stored the selected upload area before starting the transfer
• persisted the selected upload area and upload type across the transfer round-trip
• restored the persisted upload state when returning from the transfer module
• stored the temporary upload-state file outside the actual receive directory
• removed the persisted upload-state file immediately after restore

This prevents the helper state file from being processed as an uploaded file.

Problem 2: FileBase no-results handling

The FileBase "no entries found meeting your filter criteria" screen used outdated menu handling and could fail to return cleanly.

Fix

menu configuration

Updated the fileBaseListEntriesNoResults menu entry so it no longer uses the problematic old no-history behavior.

Result

After the patch:

• uploads remain in the selected file area
• the temporary helper state file is no longer imported into the filebase
• the no-results screen returns properly again

Verified locally

Example successful test:

• selected upload area: texte
• resulting storage path:
  /home/enigma/enigma-bbs/file_base/texte

Observed log flow:

• persisted upload state with areaTag: 'texte'
• restored upload state after transfer
• removed temporary persisted state file
• moved uploaded file to:
  /home/enigma/enigma-bbs/file_base/texte

Files changed

• core/upload.js
• menu configuration containing fileBaseListEntriesNoResults

Notes

This was tested locally and resolved both issues in practice.

It may still be worth reviewing whether upload area persistence should be handled more natively inside the upload/module flow, rather than requiring external persistence between menu transitions.