test(fls): the Java oracle opens files as FILIUS does (M8)

FlsOracle now loads through SzenarioVerwaltung.laden, FILIUS's full
loading path: the archive unpacked, the project's own applications copied
where FILIUS's class loader finds them, then the configuration.
--network keeps the configuration-only load (netzwerkLaden).

On the corpus this changes two files: anwendung_komplett.fls and
multicast_server.fls then have their own applications (Accumulator,
Broadcast) installed. Java's views of the written and the exported files
are byte-equal to before: Java-FILIUS 2.14 opens our exports, with the
classes they carry, as it opens a file of its own, and sees what it sees
in the original. Until own applications on hosts are written (B2), the
reader, writer and export tests leave them out (test/ownApplications.ts);
a test checks that only those two files are touched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

packages/fls/test/exportProject.test.ts

@@ -39,6 +39,7 @@ import {
   type ProjectToExport,
 } from '../src/index.js';
 import { writeTopologyXml } from '../src/topologyWriter.js';
+import { withoutOwnApplications } from './ownApplications.js';
 
 const here = dirname(fileURLToPath(import.meta.url));
 const corpusRoot = join(here, '../../../corpus');
@@ -349,7 +350,8 @@ describe('the editor model exported, as Java loads it', () => {
           return nic.mac === derived ? derived : undefined;
         }),
       );
-      const source = original[name]!;
+      // The model does not install own applications yet (B2).
+      const source = withoutOwnApplications(original[name]!);
       const nodeIds = project.graph.nodes.map((node) => node.id);
       const pairs = nodeIds.map((id) => project.remoteLinkConfigurations.get(id)?.pairIdentifier);
       // The account files of each host the export writes anew, by path, as the file has them.