Guard the vendor autoload include against symlink double-loading

[epeicher]

What it does

Requires the plugin's Composer autoloader by its realpath(), so the same physical autoload.php can no longer be included twice through two different path strings.

Rationale

When wp-content is a symlink (the WP Cloud layout), the plugin's files are reachable through two path families — the symlink path and the realpath. With opcache.revalidate_path=0 (the default), require_once does not dedupe across the two strings, so a cross-family double include of autoload.php re-declares the ComposerAutoloaderInit* class:

PHP Fatal error: Cannot redeclare class ComposerAutoloaderInitc5be971...
  previously declared in /srv/<site>/wp-content/plugins/site-export/vendor/composer/autoload_real.php   ← symlink family
  in                     /tmp/<content>/wp-content/plugins/site-export/vendor/composer/autoload_real.php ← realpath family

The export endpoint answers HTTP 500 and, in CI, import-38-flatten-wpcloud cascades (files-sync fails, nothing lands in the fs root, flat-docroot reports "ABSPATH not found"). Which leg fails varies with per-file opcache cache-key state — it hit PHP 8.1 twice, then 8.4 — the same class of symlink double-load afc8318 (#148) fixed inside export.php.

A temporarily instrumented CI run (since reverted) captured the fatal in flight and pinned the mechanism:

• the plugin bootstraps once through the symlink family, but Composer's baked __DIR__ paths resolve symlinks, so everything the ClassLoader itself pulls in — classmap classes, and eventually the colliding second autoload.php include — runs through the realpath family;
• a symbol guard (function_exists on a Composer files entry, the first attempt in this PR) is unsound: the trace showed the loader re-entered mid-getLoader(), when the ComposerAutoloaderInit* class is already declared but the files entries have not run yet.

Requiring the realpath puts this loader's include in the same family Composer already uses, so require_once dedupes natively whichever side runs first — no reliance on load-order symbols, no dependence on who the second includer is.

Testing instructions

The failure is opcache- and version-dependent, so the E2E matrix is the practical test: import-38-flatten-wpcloud exercises exactly this layout. With the fix, the full matrix went green (run failed on 8.4 before the fix; the follow-up runs pass) — the flake had fired on every recent PR run, including twice on the same leg of #383. php -l reprint-exporter-wp/lib.php passes; behaviour is unchanged when no symlinks are involved (realpath is then the same path).

[github-actions]

Pull pipeline performance — large-directory

Site: large-directory · 2,000+ plus targeted file-transfer scenarios files · 10,000 posts · 25,000 postmeta · PHP 8.5.8

Stage	PR	trunk	Δ	Status	Details
playground-sqlite-db-pull	9.39 s	9.43 s	⚪ -40 ms (-0.4%)	✓	condition=db-pull in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=lexer native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=selected trunk: condition=db-pull in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=lexer native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=selected
playground-sqlite-db-apply	3.62 s	3.65 s	⚪ -28 ms (-0.8%)	✓	condition=db-apply to SQLite in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=parser native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=verified native_ast=WP_MySQL_Native_Parser_Node sqlite_driver_parser=verified trunk: condition=db-apply to SQLite in PHP.wasm runtime=php.wasm 8.3 wp_mysql_parser=enabled mode=parser native_lexer=verified native_token_stream=WP_MySQL_Native_Token_Stream native_token_count=18 native_parser=verified native_ast=WP_MySQL_Native_Parser_Node sqlite_driver_parser=verified
Total	13.01 s	13.08 s	⚪ -68 ms (-0.5%)

_{Numbers carry runner noise; treat single-run deltas as directional, not authoritative.}

_{📈 Trunk performance history — commit-by-commit timeline.}

[epeicher]

Closing this PR: CI traces showed the fatal is not fixable at the plugin's include site. Both attempts (symbol guard, then requiring the autoloader by realpath) still reproduced the crash, because with opcache.revalidate_path=0 the same file reached through a symlink and its realpath gets two opcache identities, so require_once can't dedupe them. The real fix belongs in the E2E infrastructure (e.g. opcache.revalidate_path=1 for the FPM pools), not in lib.php.