DUPLOAI-3742: run the extension installer beside the studio

[duplodavid]

What this changes

DUPLOAI-3742: devkit runs the extension installer beside the studio, so a build in extensions/[name]/dist/ installs on its own.

• Adds an installer service on quay.io/duplocloud/helpdesk-installer, pinned by INSTALLER_TAG in .env.example, which every user's .env adopts on the next ./run.sh. The compose file defaults to that pin, so docker compose up before then still starts
• Points the studio at it through Extensions__InstallerUrl, and hands it the JWT secret and the license token from .env and none of its LLM, AWS or admin credentials
• Leaves the license-server catalog off unless LICENSE_SERVER_URL is set
• deploy-extension.sh on a build under extensions/ hands it to the installer while it runs, waits for the installer to report that zip, and exits non-zero with the installer's reason. It posts the zip itself only for a build the installer leaves alone, a zip elsewhere, a remote target, or with the installer stopped, so the agent skill's deploy step no longer races the installer
• The installer installs a dist/ build only once it changes while the installer runs, so a build on disk at start (as after ./run.sh --reset), a removed extension, and a build older than a working installed version stay as they are. The image INSTALLER_TAG pins predates that, so this holds once a follow-up moves the pin
• The ready banner and the install doc send the bundled sample through deploy-extension.sh, since that build never reaches the installer. A pass with no selection key installs nothing. The docs also cover the manual recovery when a build hangs the studio at load, and how to read the installer's status when a build never loads
• The Available tab hands Install to this installer only once the UI tag and the studio tag in .env.example are images that do that. The tags pinned there predate that handoff

How it was verified

• ./run.sh --reset, then built and deployed a sample end to end
• ./scripts/build-extension.sh on the affected sample, then deployed it and created one in the UI
• npm ci && npm run build in the affected frontend/
• ./stop.sh --wipe && ./run.sh from a clean slate
• Ran /duplo-extension and confirmed the guidance still matches reality
• Docs only - no runtime behavior changed

Output

$ bash tests/test-installer-wiring.sh
37 passed, 0 failed
$ bash tests/test-deploy-extension.sh
11 passed, 0 failed

Blast radius

• This changes .env.example - image tags or ports here are adopted into every user's
  .env on their next ./run.sh after an upgrade. Say so plainly above.
• This changes scripts/upgrade_dev_kit.sh or scripts/init-project.sh - the adoption path
• This changes a workflow under .github/workflows/
• None of the above

Checks

• No .env, tokens, keys, or customer identifiers in the diff
• No build output committed - dist/, node_modules/, **/bin/, **/obj/, backend/sdk-packages/
• Commits are conventional, imperative, and focused
• If a vendored ng-common-lib tarball was added or bumped, its NOTICE sits beside it

[gk-duplo]

remove-extension.sh deletes the row but leaves the zip in dist/, and for a local build the installer reads "no row + a build in dist/" as an install (the table only returns not-requested when there's no LocalPath). Removal doesn't change the fingerprint, so nothing happens right away, but the extension comes back on the next trigger: any other build, a studio restart, or the next ./run.sh. The only ways to keep it gone are disabling it in the UI, deleting dist/, or EXTENSIONS_EXCLUDE. Worth saying here, or better, have the local source only install a zip that changed while the installer was watching rather than every zip on disk.

[duplodavid]

Fixed in the installer the second way you suggested, and cd37817 documents it in the README. The installer now installs a dist/ build only once its zip changes while it runs, so a removed extension stays gone until its next rebuild. The image INSTALLER_TAG pins predates that, so devkit picks it up when a follow-up bumps the pin.

[gk-duplo]

The local source takes ownership of every installed id that has a build in dist/, whatever version is installed, and the table then installs whenever the installed version differs from the dist version. It never checks which is newer. So if v1.2 was loaded another way (Extension Studio's in-platform flow, or a zip outside dist/), a stale v1.1 zip left in dist/ rolls it back on the next pass. Can the local source skip a build older than the current row?

[duplodavid]

Fixed in the installer, and cd37817 documents it. It skips a dist/ build older than a working installed version, with a detail naming both, and deploy-extension.sh loads it if you hand it that build on purpose. A newer version that failed to load still takes the older build, so rebuilding back to a working version needs no extra step. The image INSTALLER_TAG pins predates that, so devkit picks it up when a follow-up bumps the pin.

[gk-duplo]

Since this volume goes with down -v, ./run.sh --reset now wipes the installer's state along with Mongo, and the first pass after the studio comes up loads every extensions/*/dist/extension.zip. Anyone resetting to get an empty platform gets all their old builds back about 20 seconds later. Either document that, or don't treat zips that were already on disk at startup as install requests.

[duplodavid]

Fixed in the installer the second way, and cd37817 documents it. A build already in dist/ when the installer starts waits for its next rebuild, so ./run.sh --reset comes up empty. The image INSTALLER_TAG pins predates that, so devkit picks it up when a follow-up bumps the pin.