fix(devloop): keep resource edits made since app start when re-seeding (#25958) (CP: 25.3)

[vaadin-bot]

This PR cherry-picks changes from the original PR #25958 to branch 25.3.

Original PR description

Summary

If you edit a pom and application.properties at the same time while the app runs, the dev loop could lose the properties edit. It never restarted the app to pick it up. With this fix, resource files changed after the app started are no longer marked as already handled when the baseline is rebuilt.

Fixes #25956

What changed

• Behavior change: A pom edit that changes the module set rebuilds the change baseline while the app runs. During that rebuild, Compile.seedResources now skips resources modified after the app started. Before, only sources and frontend files were skipped. So a resource edit in the same batch was treated as done. The Maven re-resolve had already copied it onto the classpath, apply reported "Stable" without a restart, and no later apply saw the edit again. Now the edit shows up as a startup resource change and triggers a restart. This only affects dev loop users who edit resources together with the pom.
• The no-argument seedResources() works as before (it seeds everything).
• Internal change only: Compile is package-private, so there are no public API changes.

Test summary

Resource re-seeding (Compile):

• Config edited after app start reported as a startup change after re-seed, even when its classpath copy is up to date
• Resources the app started with stay seeded (no live changes reported)

[github-actions]

A resource edit made after app start now survives the baseline re-seed instead of being absorbed into it

flowchart LR
    subgraph Before
        direction TB
        B0["compileFor re-seeds baseline"] -->|"seedFromDisk"| B1["seedResources() seeds every resource"]
        B1 -->|"stamps edited application.properties as notified"| B2["staleResources()"]
        B2 -->|"copy current and stamp matches"| B3["startup() empty; reports Stable, no restart"]
    end
    subgraph After
        direction TB
        A0["compileFor re-seeds baseline"] -->|"seedFromDisk startedAtMillis"| A1["seedResources(startedAtMillis) skips newer resources"]:::changed
        A1 -->|"leaves edited application.properties unstamped"| A2["staleResources()"]
        A2 -->|"stamp missing so reported"| A3["startup() non-empty; escalate to restart"]:::changed
    end
    Before ~~~ After
    classDef changed stroke:#c9a227,stroke-width:3px

Loading

When a pom edit changes the module set, TransactionEngine.compileFor rebuilds the baseline through Compile.seedFromDisk, which now forwards the app's start time to Compile.seedResources. Before, seedResources() stamped every resource as already handled, so an application.properties edited after startup matched the baseline in staleResources() and never reached staleResources.startup() — apply reported Stable with no restart (per #25956). After, resources newer than app start are left unstamped (the node marked in gold), so the edit surfaces as a startup change and escalates to a restart at TransactionEngine line 513.

Diagram Bot draws the mechanism this pull request touches; it does not review the change. Verify it against the diff.

Generated by Diagram Bot for issue #25987 · ◷

[vaadin-bot]

This PR is eligible for auto-merging policy, so it has been approved automatically. If there are pending conditions, auto merge (with 'squash' method) has been enabled for this PR [Message is sent from bot]

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Test Results

 1 442 files  ±0   1 526 suites  ±0   1h 31m 28s ⏱️ + 5m 12s
11 850 tests +1  11 782 ✅ +1  68 💤 ±0  0 ❌ ±0 
12 206 runs  +1  12 138 ✅ +1  68 💤 ±0  0 ❌ ±0 

Results for commit 8b17f53. ± Comparison against base commit caff63b.