feat(drive): an operation to unpublish an app stream entry #13

The route table publishes apps and cannot remove them: POST /SASjsApi/drive/deploy and POST /SASjsApi/drive/deploy/upload are there, nothing deletes an entry. On a server that has been used for a while the result is a listing nobody can clean up - the estate I hit had 22 entries, 13 of them pointing at Data Controller appLocs, several at folders that no longer exist.

What happens today on sasjs/server 3.14.0

• The AppStream listing and its HTML index are built from a registry at <driveLoc>/appStreamConfig.json, loaded once at startup into process.appStreamConfig.
• The only writer is publishAppStream. removeEntryFromAppStreamConfig exists in api/src/utils/appStreamConfig.ts but has no caller and no route.
• The registry sits one level above the drive root the API exposes (/home/<user>/sasjs_root/drive/appStreamConfig.json against a drive root of .../drive/files), and /SASjsApi/drive/file refuses to reach it - Can't get file outside drive.
• GET/DELETE/PUT /SASjsApi/drive/deploy all answer 404, so the only way to remove an entry is editing that file on the host and restarting the server.

That leaves stale apps advertised to every permitted user, and a link that answers 401 or 404 when clicked.

What I would expect

DELETE /SASjsApi/drive/deploy with { appLoc, streamServiceName } that

• removes the entry from the registry and persists it, so both the JSON listing and the HTML index stop advertising the name;
• removes the AppStream permission grant that publishing added for that name, so it also drops out of a user's allowed paths;
• leaves the drive content alone - deleting the folder stays an explicit DELETE /SASjsApi/drive/folder, so unpublishing and destroying are separate decisions;
• answers 404 when the name is not in the registry, and 403 naming the capability when a host does not support it, in line with the overlay's capability handling.

POST /SASjsApi/drive/deploy is currently implemented: false in the overlay, so the removal operation presumably wants the same treatment and to land alongside it.

One caveat for whoever picks this up: the route table is generated from sasjs/server's OpenAPI document, and the README's rule is that the document is corrected upstream and re-vendored here rather than worked around in the overlay - so this needs the operation added in sasjs/server first (route, controller, removeEntryFromAppStreamConfig wired up, swagger), then npm run sync:routes here.

Happy to write it if that split works for you.