chore: reexamine eslint-disable instances and resolve if applicable

[TillaTheHun0]

linting was added as part of #200 . Part of that PR went through files to manually disable linting rules in files that did not seem quite ready to be updated to conform to linting rules. This includes:

• Files with unused variables (they seem to be documenting a contract, so didn't want to remove them)
• Files with duplicate declarations ie. exported TypeScript type having the same name as an exported object
• Files accessing global variables ie. fetch added to globalThis farther up the require chain

Each of these instances where eslint rules were ignored should be reexamined and solutioned, if appropriate. For example:

• unused variables being used to document a contract should instead by replaced by a type, jsdoc module, etc.
• Files with duplicate declarations should be consolidated to where the TypeScript type and the object are the same export
• Files accessing global variables should instead leverage dependency injection. If a file must continue to access a global variable, then perhaps the solution is updating globals in .eslintrc.js or even just keeping the comment in the file, as is and adding a justification why in a subsequent comment.

each instance eslint-disable would be solutioned on a case by case basis

[TillaTheHun0]

eslint is removed as part of #230 . This can be closed.