fix: create internal application when plugin adds Messenger after init

[TowyTowy]

Fixes #653

Problem

When a plugin implements the plugin.Messenger interface after it has already been initialized for a user, its PluginConf already exists with no associated internal application (ApplicationID == 0). On the next startup, initializeSingleUserPlugin reuses that conf and wires the message handler with ApplicationID: 0, so every message the plugin sends is stored with application_id = 0. Those messages are orphaned: they don't appear after a page refresh and can't be deleted (DELETE returns 404). This matches the maintainer's diagnosis in #653.

Fix

On initialization, if a plugin supports Messenger but has no internal application yet (ApplicationID == 0), create one and persist it on the conf — mirroring what already happens for plugins that support Messenger from the start. The internal-application creation is extracted into a shared helper. The back-fill is idempotent: plugins that already have an application are untouched.

Testing

Added TestNewManager_MessengerAddedAfterInit_createsApplication, which seeds a conf without an application and asserts an internal application is created after re-initialization with a Messenger-capable plugin. It fails on master (ApplicationID stays 0) and passes with this change. go test ./plugin/..., gofmt/gofumpt, and go vet are clean.

---

Disclosure: this change was prepared with assistance from Claude (an AI tool); all code was reviewed and verified by me.

[codecov]

Codecov Report

❌ Patch coverage is 65.00000% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.25%. Comparing base (e54c8ac) to head (8c03d26).

Files with missing lines	Patch %	Lines
plugin/manager.go	65.00%	3 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #998      +/-   ##
==========================================
- Coverage   74.34%   74.25%   -0.09%     
==========================================
  Files          66       66              
  Lines        3461     3473      +12     
==========================================
+ Hits         2573     2579       +6     
- Misses        688      691       +3     
- Partials      200      203       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eternal-flame-AD]

looks good to me, just one thing: can you add a double check in messagehandler.go to do a final check that the application ID is not zero? thanks. I wish we have foreign keys working.

[TowyTowy]

Done. Added the safety net in messagehandler.go: SendMessage now returns an error if ApplicationID == 0 rather than queueing a message that would be stored with application_id = 0 and orphaned. Also added tests covering it and the internal-application back-fill error paths, which should clear the codecov patch/project checks. Agreed on the foreign keys wish.

(Prepared with AI assistance, reviewed and verified by me.)