PHP static-property usage ranges omit the sigil

[DavidBakerEffendi]

php-parity-static-property-access still fails under Bifrost v0.10.5, but the
failure has moved from resolution to usage ranges. This is the remaining half
of the PHP sigil work and needs a Bifrost-side fix.

What changed

BrokkAi/bifrost-dev#2416 fixed the declaration side, and it works —
php-property-access now passes end to end (#160). For this case, resolution
now succeeds too:

	v0.10.1	v0.10.5
selector	— (symbol_resolution_failed)	App.Service.EmailNotifier.sent (found)
declaration lookup	wrong_target	ok
usages	2 missing, 0 unexpected	2 missing, 2 unexpected

The remaining defect

Bifrost now returns the usage sites, one column short at the start:

expected	returned
EmailNotifier.php:16:15-20	16:16-20
Consumer.php:10:18-23	10:19-23

The source is self::$sent++. Column 15 is the $, so 15-20 spans $sent
and 16-20 spans sent.

Why the ground truth is right here

PHP writes the sigil at a static property usage — self::$sent,
EmailNotifier::$sent — so the $ is part of the written token and belongs in
the range. Instance access is written $this->last, where the property token
is last with no sigil, and the corpus expects it without one. Bifrost gets
that case right, which is why php-property-access passes.

So the two shapes genuinely differ, and the audited expectations reflect the
language rather than an inconsistency.

Note for whoever picks this up

The bifrost-dev investigation for #2416 concluded:

Static-property usage ranges already included the sigil, and ->last
instance usages correctly don't. No usage-side change was needed

That does not hold at v0.10.5 — measured above. Either the behaviour differs
from what was checked, or the declaration-side fix did not extend to static
usage sites. Worth establishing which before changing anything, and worth not
taking the earlier note at face value.

Blocks nothing: this case is in the expected-failure set for the v0.3.1 freeze
(#155) and a failure is recorded honestly rather than gating publication.

[DavidBakerEffendi]

Re-measured: the reference PHP LSP includes the sigil

A claim came back from the Bifrost side that the sigil-exclusive form is
"consistent with PHP LSPs" and that this is therefore a usagebench change.
That is not what the reference LSP does. Measured just now, not quoted from the
audit:

cargo run -- run-lsp benchmarks/cases/php-lsp-parity.yaml \
  --profile adapters/lsp/intelephense.json

php-parity-static-property-access, declarationToUsages, rawStatuses: ["ok"]:

	ranges
expected (ground truth)	EmailNotifier.php:16:15-20, Consumer.php:10:18-23
Intelephense 1.18.5 returned	Consumer.php:10:18-23, EmailNotifier.php:16:15-20
Bifrost v0.10.5 returns	16:16-20, 10:19-23

Zero missing, zero unexpected against Intelephense. It matches the authored
expectation exactly, sigil included.

Why the case still shows UNSUPPORTED for Intelephense

Worth stating so the label is not mistaken for disagreement: Intelephense does
not advertise textDocument/declaration, so the declaration-lookup
operation is unsupported and the case is excluded from that scored comparison.
The reference ranges are a separate operation, and they ran and came back
ok. So "unsupported" here means "this server does not offer that one
operation", not "this server disagrees about the ranges".

This also matches the July audit note, which recorded the same result
independently:

The declaration, internal write, and external read all spell the static
property token as $sent, so their exact ranges include the PHP sigil. …
Intelephense 1.18.5 returned both full $sent usage ranges.

Where that leaves the fix

PHP writes the sigil at static access (self::$sent, Mailer::$sent) and not
at instance access ($this->last). The corpus expects each accordingly,
Intelephense produces each accordingly, and Bifrost already gets the instance
case right — which is why php-property-access passes after
BrokkAi/bifrost-dev#2416. Only the static usage site is short by one column.

So the ground truth is not the thing that is out of line, and this remains a
Bifrost-side fix. If the Bifrost investigation measured a different server, or
phpactor rather than Intelephense, that would be worth naming explicitly —
phpactor is the parity source for this case, but Intelephense is the
registered reference profile the comparison scores against.