fix(ci): ensure monthly plugin framework update workflow creates PR correctly

[Aaravanand00]

Summary

This PR improves the automated workflow that updates the Joplin plugin framework.

Changes

• Replace npm ci with npm install --legacy-peer-deps to prevent peer dependency failures.
• Add a change-detection step using git diff --quiet to avoid creating empty PRs.
• Improve commit message and PR title for clarity.
• Add delete-branch: true to prevent branch conflicts when the workflow runs again.

Notes

All existing tests pass locally and the changes are limited to the GitHub Actions workflow.

[nishantwrp]

Hi @Aaravanand00, I'm sensing that you're using ai to help with fixing issues which is okay as long as it's inline with joplins ai-assisted contributions guidelines.

But in your recent pull requests, I've noticed a pattern of

• Changes that are not tested locally
• Not replying to my review comments repeatedly
• Pasting AI generated repsonse as description & comments

For those reasons, I'm going to close all your pull requests. Also, take a look at https://discourse.joplinapp.org/t/policy-on-ai-assisted-contributions-during-gsoc-2026-draft/48706/14?u=nishantwrp

[Aaravanand00]

Hi @nishantwrp,

First of all, I'm really sorry about this.

You're right that I didn't reply to your review comments in the PR threads. When I saw your comments, my approach was to implement all the requested changes first and then explain them afterwards. Looking back, that was a mistake — I should have replied directly to each comment and discussed the changes there instead of staying silent. I’ll make sure to do that going forward.

Regarding the descriptions and comments looking AI-generated: I actually write the PR descriptions myself. The reason they may look structured is because I usually format them using headings (###) and bullet points (-) so that the changes are easier to read and review. But I understand how that pattern might look similar to AI-generated text, and I’ll keep the descriptions simpler from now on.

About local testing: I always test the changes locally before pushing. I run the commands locally and also verify the tests (npm test) before opening the PR. I can also share screenshots of the terminal outputs for each PR showing that all test cases passed locally.

I completely understand the concerns you raised, and I appreciate you pointing them out. I’m learning how to contribute better and follow the project’s expectations more closely.

If possible, could you please consider reopening the PRs?