Item visibility is reserved in the GID and absent from the language

Found while testing unsafe fn against visibility markers (Vx#484): there are none. This records what exists, what does not, and what will have to be decided when it lands.

Reserved. src/gid.rs defines three visibility states and a mask to read them from the identifier's flags word:

const VISIBILITY_MASK: u64 = 0xF000_0000_0000_0000;

pub fn visibility(&self) -> Visibility {
    let vis_bits = (self.words[3] & VISIBILITY_MASK) >> 60;
    match vis_bits {
        0 => Visibility::Private,
        1 => Visibility::CratePublic,
        2 => Visibility::FullyPublic,
        ...

Absent. There is no pub token in the lexer, Visibility:: is constructed nowhere outside gid.rs, and no .vx file in the repository writes one. Every spelling is rejected by the top-level dispatch, pub simply lexing as an ordinary identifier:

pub fn f() -> i32 { ... }          Error at 1:1: Unexpected token at top level: Identifier("pub")
pub(crate) fn f() -> i32 { ... }   Error at 1:1: Unexpected token at top level: Identifier("pub")

This is the same shape as the memory-space slot on Type::Pointer (Vx#480): a field with three defined states that nothing ever fills.

What it will have to decide, when it lands.

1. Parse order with unsafe. parse_function consumes an optional unsafe before fn, and the dispatch recognises a function declaration by at_fn_start(), which matches fn or unsafe fn. A visibility prefix has to be admitted there too, and one order has to be chosen (pub unsafe fn, following Rust) and the other refused with a message rather than a generic "unexpected token".
2. The library interface. FnSig now carries is_unsafe so an importing module can refuse a call without seeing the body. Visibility is the same kind of fact and wants the same treatment, with a sharper consequence: a crate-public function should not be callable across a library boundary at all, so the interface either omits it or marks it. That is a vxlib-interface format decision, not only a checker one.
3. Identity. Visibility currently sits in word 3, which the derived equality and hash compare, so setting it changes the identifier. is_unsafe was deliberately kept off word 3 for that reason (Vx#484). Whether visibility belongs in identity is a real question — two functions differing only in visibility arguably are different entities in a way that unsafe is not — but it should be answered, not inherited.

No behaviour is wrong today; nothing reads the bits. Filed so the reservation is not mistaken for an implementation.

Start by reading src/gid.rs, then trace parse_function and at_fn_start through the lexer and top-level dispatch. Review FnSig and the vxlib-interface format before deciding how visibility should be parsed, exposed, and represented in identity. Done means the open design questions have explicit decisions and a scoped implementation plan.