Emit HatSet at initialize() in HybridVoting & DirectDemocracyVoting (creator/voting hats)

[hudsonhrh]

Problem

HybridVoting._initializeCreatorHats() and DirectDemocracyVoting.initialize() seed their creator hats (and, for DDV, voting hats) via HatManager.setHatInArray(...) without emitting any event. Only the post-deploy setters (setCreatorHatAllowed, setConfig(HAT_ALLOWED)) emit HatSet/CreatorHatSet.

The subgraph builds the Creator/Voter HatPermission rows purely from those events, so any creator/voting hat granted at deployment is never indexed. Result: the org permissions matrix under-reports who can create proposals/polls.

Concrete: on Decentral Park (Gnosis), on-chain HybridVoting.creatorHats() = [Neighbor, Delegate, Agent], but the subgraph shows only Agent — because Agent is the one creator hat that happened to be re-set post-deploy (the only HatSet the contract ever emitted). Neighbor + Delegate were set at initialize() and are invisible.

Why this is the right fix

TaskManager.initialize() already emits HatSet(HatType.CREATOR, hat, true) for each creator hat — and the subgraph indexes those reliably. The voting contracts should do the same. This makes the subgraph fully event-sourced (no eth_calls, which are fragile during re-sync — see the workaround in subgraph-pop #186 that stalled indexing).

Proposed change

• HybridVoting — in _initializeCreatorHats, emit HatSet(HatType.CREATOR, creatorHats[i], true) inside the loop.
• DirectDemocracyVoting — in initialize, emit CreatorHatSet(hat, true) for each initialCreatorHats[i] and HatSet(HatType.VOTING, hat, true) for each initialHats[i].

(Mirror exactly what TaskManager.initialize does today.)

Note on existing orgs

A contract upgrade only fixes future orgs (init has already run for deployed ones). Existing orgs (e.g. Decentral Park) would need a one-time governance re-set of their creator hats to emit the events — or, as an interim, the frontend reads creatorHats()/votingHats() directly via RPC (poa-box/Poa-frontend#436).