Могу ли я не попасть на какую-либо строку, или попасть дважды после update

BOL - Accessing and Changing Relational Data - Cursors - Cursor Types - Forward-only Cursors

"Because the cursor cannot be scrolled backward, however, changes made to rows in the database after the row was fetched are not visible through the cursor, except for the case where a value used to determine the location of the row within the result set is modified, such as updating a column covered by a clustered index."

Ну ведь ясно написано, что это может произойти если в результате изменения записи изменится значение, с помощью которого определяется положение записи в курсоре. Как явный пример, это изменение столбца, входящего в кластерный индекс.

А вот каким образом сервер выбирает "a value used to determine the location of the row" - это вопрос. При наличии первичного ключа или поля с identity IMHO все просто - они и будут этим значением. А вот при их отсутствии сервер может выбрать и совокупуность всех полей в качетве ключа, а может и что-нибудь свое "придумать".
Угадать, имея в наличии только информацию о том, что временная локальная таблица #sel содержит поля qty, _hide и olongid плюс еще что-то, я не возмусь.
Хотя я бы исходил из наихудщих предположений.

Еще раз
Вопрос не в том, по каким полям "ходит" курсор, а в том, что он будет использовать для определения местоположения строки в наборе ("to determine the location of the row within the result set").
Если в вашей таблице только 3 поля - qty, _hide и olongid (во всяком случае в вашем примере видны только они) - причем ни одно из них не является первичным ключом, то IMHO может случится и зацикливание курсора, т.к. сервер может сам использовать поле _hide для идентификации строк курсора. А его-то вы как раз и обновляете.
Если же например поле olongid уже есть первичный ключ, то ничего подобного не произойдет.

Резюме.
Чем гадать, каким образом поступит серевер в спорной ситуации, лучше не допустить такой ситуации.