[Question]: Build manifest and matching Linux WPE WebKit debug symbols for revision 2359

Could a maintainer supply the build manifest/generated CMake configuration and
matching separate debug symbols for this shipped Linux x86_64 library, or
confirm that they are unavailable?

• Playwright 1.63.0, WebKit 26.6, Linux bundle revision 2359
• Ubuntu 24.04, headless WPE, DPR 1
• Library: libWPEWebKit-2.0.so.1.12.0
• ELF build ID: 942dcd0e69274d8ded5d3db02e52d97d65b193ca
• SHA256: 830ab277f4de888a75b576ef89efde5f7daa45436e9f4a90b677da120baffea3
• WPEWebProcess SHA256:
  70683ba57c05ce81d43601e1c89701e7016c76136ae810b000cd786085091b4a
• Release UPSTREAM_CONFIG.sh pins WebKit base
  4d05d732e5a84f32675bef4cc135a2e7a9269a87, plus Playwright patches.

If symbols were not retained, could you provide the exact build recipe,
toolchain/dependency versions and effective feature flags used for this bundle,
and the way to build that base with the corresponding Playwright patches
without stripping debug information? In particular, which graphics/text
backend was enabled (USE_SKIA, Cairo, FreeType/HarfBuzz)? A current upstream
default is not enough to identify the shipped configuration.

Why these are needed

We are tracing Arabic stacked-mark placement beyond hb_shape. The loaded
shaper in the rendering child is system HarfBuzz 8.3.0
(/usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.60830.0). A forwarding
interposer records the original call and replays its public inputs/properties
against the same hb_font object and loaded shaper. Original/replay glyph
IDs, clusters, advances and offsets agree. Instrumented and uninstrumented
lossless canvas masks agree and retain the placement discrepancy.

At 36px with the pinned DejaVu Sans font (SHA256
ae7b7855e115a5966d8b1b3f80f254ccc117ec86f9965e202ee2940453837280):

• Composite case: source 0643 0651 064E 062A 0628; glyphs
  5258,5266,6020,5333; GSUB selects combined mark glyph 6020, cluster 1,
  zero advance, offset (-301824,+403200) (divided by 65536:
  (-4.60546875,+6.15234375)). This is not two independently positioned
  marks. We do not equate this composite's origin with the reference's
  separate component origins.
• Descending pair: source 0621 064D 0650 062A 0628; glyphs
  5258,5265,1401,1398,1359; kasra glyph 1401 returns y-offset
  -576000 (divided by 65536: -8.7890625).
• Descending chain: source 0621 064D 0650 0650 062A 0628; glyphs
  5258,5265,1401,1401,1398,1359; last kasra returns y-offset
  -921600 (-14.0625) and the preceding kasra retains -576000.
  Pair/chain native ink ends at y=112, while the independent font-anchor
  references end at y=118/123.

These observations do not establish a HarfBuzz defect or prove which
downstream stage changes or consumes the positions incorrectly. Same-object
replay is only a determinism control, not independent validation of font
callbacks/setup.

The shipped library is stripped, without .symtab or .debug_* sections.
The relevant run-construction and paint methods are not dynamically exported;
interposing hb_shape cannot observe those internal boundaries. With matching
symbols or a source-instrumented build, we intend to correlate per-draw glyph
IDs/clusters, advances, offsets, font/run scales and transforms at shaping
return, internal run conversion, glyph-buffer construction and paint submission.

This is a provenance request, not a claim of a confirmed backend defect or a
Safari/CoreText reproduction. Composite and descending cases remain separate.
A concrete confirmation that the exact manifest/symbols are unavailable would
also help us document the instrumentation limit accurately.