I don't have any rails experience but have come across similar when handling default values for 1 to many relationships and have usually gone with something like this for db schema:
table Parents
id
table Children
id
parent_id
FK (parent_id) references Parents(id)
table PromotedChildren
child_id
parent_id
FK (child_id, parent_id) references Children(id, parent_id)
UNIQUE Key parent_id
Edit
After answering this it got me thinking why I prefer this representation over the others, so I did a bit more research and gave it some more thought:
table Parents
id
table Children
id
parent_id
is_promoted
This with a unique constraint on (parent_id, is_promoted) as proposed by Jef would work if nulls are ignored by the db, as suggested by Kelvin, and may be a good option. However, some might argue that using null as a substitute for false/0 is incorrect usage of null and it effectively turns the field into tri-state ie 1, 0, unknown. Also (parent_id, is_promoted) is not a superkey and as such violates Domain Key Normal Form.
table Parents
id
promoted_child_id
table Children
id
parent_id
As you pointed out this may cause cycles and by making promoted_child_id an FK that references Children(id) you still are at risk of database anomalies where ParentA lists ParentB's child as promoted.
table Parents
id
table Children
id
parent_id
promoted_parent_id
Here you get the risk of anomalies as described; a unique key on promoted_parent_id must also rely on the db ignoring nulls; multiple cascade paths; redunancy as promoted_parent_id and parent_id should be the same; update anomalies where parent_id does not match promoted_parent_id.
table Parents
id
table Children
id
table ParentChildRelationship
parent_id
child_id
is_promoted
This looks more like a many to many representation of parent to child. It presents similar problems to the others above.
As to what is most practical for rails development I cant say. I have used both the representation I put forward and Jef's with C# and PHP and haven't really noticed a difference.