Strip a UTF-8 byte-order mark before parsing a reward scaffold - #48

Found while verifying the published v0.6.3 wheel: a reward scaffold saved
with a UTF-8 byte-order mark — what a Windows editor produces by default — was
reported as unparseable.

status : fail
level  : not_present
categories : ['syntax_error']

CPython strips the BOM when it reads a source file, so that scaffold imports
normally. The static checker decoded the bytes and handed the leading U+FEFF
to ast.parse, which rejected it.

The direction is fail-closed: a legitimate file was refused, nothing unsafe was
accepted. So this is a robustness defect, not a security one — but it would
have made bridge doctor unusable for anyone whose editor writes a BOM.

v0.6.3 is immutable and keeps the behaviour; this lands in 0.6.4.

Regressions

• a BOM-prefixed valid scaffold reaches interface_shape_verified with no
  findings;
• a BOM-prefixed scaffold with a top-level exploit() is still rejected with
  top_level_call, still never executes, and still creates no marker file.

The second one matters more than the first: the fix must not turn the BOM into
a way to slip past the checker.

Also recorded

pinned-profile-smoke is documented as deliberately excluded from the
required-status-check list. verl-bridge.yml filters on paths, so it never
reports on a pull request that does not touch bridge code — requiring it
blocked the v0.6.4 state-sync PR permanently until it was removed. It still
runs, and must pass, wherever it is relevant.

Validation

1832 CPU tests pass (2 new), ruff / format / mypy clean.