What do you hope to achieve by reinventing trac and then recreating the interface within Code::Blocks?
Speed and usability of course, it would be far more comfortable doing
Right-click->Add issue inside C::B, navigating the current issues without leaving the IDE (thus with zero possible distraction), integrating TODO lists from C::B with it, and you can think a lot more possibilities.
The "I" in IDE is for Integrated, so sure you can use external documentation/bugtracking/compilers/whatever, but it's more comfortable to have everything in one place.
If you really wanted that kind of information in the IDE, you could make a plugin for trac that allows remote use, and then a C++ client for Code::Blocks and save yourself lots of time.
Well, that's a very good option too and it will save lots of time reinventing the wheel.
However it faces a little problem:
trac itself and it's
python dependency.
To put it simply, PHP is far more extendend in hostings than Python, aside that trac is not easy to install.
Having a SQlite backend (without more dependencies) as a C++ C::B plugin would mean that it will not requiere having to install any server software (be it apache/mysql/whatever) to use it in a local way (common usage for a 1-person development).
And having the DB in SQlite would mean that it will be easily accessed from PHP from a web interface (common usage for a team development).
But in a way, I think the best-fit-all solution would be to use the current Trac SQlite DB schema (and make compatible with it).
That will save from initially having to write the Web code, thus reusing Trac, and if it later proves to be worth, write a PHP version.
Put it simply, the C::B version will not have any Trac dependency, but it will be DB-compatible.