Is there an erratum in the Bluetooth spec AUX_ADV_IND example?

The Bluetooth Core specification gives, in section 6.C.4.2.2 (p.2909), an example Extended Advertising PDU:

PDU:
11100000 00001000 01010010 10010010 01110101 10110101 00110101
11010101 01010101 10010101 00111101 01010111 01101011 10100000
11100000 10010000 11010000 10110000
CRC:
00011011 11000100 01110101

This part of the packet is the only part handled by the CRC algorithm defined in Section 6.B.3.1.1, pp.2733–4. Note that it matches the whitened sequence beneath, without error:

$ perl -e '$c=0x71;$a="11100000 00001000 01010010 10010010 01110101 "
   ."10110101 00110101 11010101 01010101 10010101 00111101 01010111 "
   ."01101011 10100000 11100000 10010000 11010000 10110000 00011011 "
   ."11000100 01110101"; for$d(0..length($a)-1){$e=substr($a,$d,1); 
   if($e=~y/01//){$c+=$c;if($c&0x80){$c^=0x91;$e=~y/01/10/;}} 
   print$e;}print"\n";'
00011100 01111110 01111011 11101111 00100101 00000010 10101001
01111001 10010100 00100000 11101100 11000110 01101001 11101101
11011101 01010011 00101000 01011100 01001001 00111110 11010100

However I have been unable to regenerate the expected CRC. As an advertising packet it presets the CRC shift register to the constant 0x555555, to which the model in CRC RevEng defaults:

$ reveng -m crc-24/ble -c 07104a49aeadacabaaa9bcead60507090b0d
a68bc4

Expanded to binary, this answer would appear as:

01100101 11010001 00100011

A single bit flip in the message, 0x07 → 0x27 in the first byte, yields the CRC as stated (here as its hex equivalent):

$ reveng -m crc-24/ble -c 27104a49aeadacabaaa9bcead60507090b0d
d823ae

But the whitened sequence reinforces the original (or else both are wrong). Instead a modified Init vector 0x515555 has the same effect as the bit flip, and elicits the given result:

$ reveng -m crc-24/ble -i 515555 -c 07104a49aeadacabaaa9bcead60507090b0d
d823ae

This constant appears nowhere in the Bluetooth spec, nor is there any sign of how it might be derived.

So, what gives? Is the Init vector supposed to be 0x515555 in this case? Are both the Spec's copies of the PDU wrong? Or, was the CRC miscalculated in the example?