Advertise repeat capability via capabilities bitmask

[wbijen]

Summary

Implements #1906 — nodes that forward packets but aren't dedicated repeaters (room servers with repeat enabled, companions with client_repeat) can now advertise this via a capabilities bitmask in the existing FEAT1 advert field.

This helps companion apps distinguish relay-capable nodes in path displays and resolves hash collisions where a room server was being confused with a repeater (as reported in #1866 and #1707).

What changed

• Renamed the generic FEAT1 internals to "capabilities" — ADV_FEAT1_MASK → ADV_CAPS_MASK, setFeat1()/getFeat1() → setCapabilities()/getCapabilities(), _extra1 → _caps. The old name was a placeholder that didn't communicate intent; "capabilities" is the standard term for this pattern in network protocols (Wi-Fi, BLE, etc.).
• Added ADVERT_CAP_REPEAT (0x0001) — first bit in the new capabilities bitmask, meaning "this node forwards packets".
• Room server sets ADVERT_CAP_REPEAT when repeat is enabled (!disable_fwd).
• Companion radio sets ADVERT_CAP_REPEAT when client_repeat is on (3 call sites: manual advert, self-export, periodic advert).
• Dedicated repeater sets ADVERT_CAP_REPEAT for consistency, even though ADV_TYPE_REPEATER already implies it.

Backwards compatibility

Fully backwards compatible in both directions:

• Old clients that see the ADV_CAPS_MASK bit simply skip the 2-byte field (this was already wired up in the parser).
• Old firmware sends caps = 0, so the field is omitted from the wire — no extra bytes.

Future capabilities

The uint16_t bitmask has 15 bits remaining. Some ideas that came up during discussion:

Bit	Idea	Rationale
0x0002	ADVERT_CAP_GPS	Node has GPS hardware — apps could distinguish real GPS location vs manually entered coordinates
0x0004	ADVERT_CAP_TELEMETRY	Node has sensors — apps would know they can request telemetry data from this node

These don't have concrete firmware/app consumers yet, so they're not included in this PR — just noted here for future reference.

Test plan

• Builds cleanly against heltec_v4_companion_radio_usb
• Builds cleanly against heltec_v4_room_server
• Builds cleanly against heltec_v4_repeater
• Builds cleanly against heltec_v4_sensor (unchanged, still passes caps = 0 via default)
• Verify on-air: companion with client_repeat on → advert includes FEAT1 field with 0x0001
• Verify on-air: room server with repeat → advert includes FEAT1 field with 0x0001
• Verify old companion app still parses adverts correctly (skips unknown 2 bytes)