I would still class anything that is common to more than one game (or code that is modular and potentially re-useable or multipurpose) as 'engine/framework code', rather than the actual 'game code'.
Yes, that's what an engine is, basically. But just because it's recyclable doesn't mean it's any less of the actual game.
For example, I'm working on programming the game engine for our current project. It takes care of a lot of things, like loading planets (asynchronously) and stars, managing the coordinate system so floating point precision errors don't occur, managing planetary terrain LOD, atmospheric scattering, physics, shaders, etc.
You can't just swap out our engine for some generic thing (like Torque), keeping only the scripts - it wouldn't work. There's too much code embedded in the engine that relates to the game itself, like the assumption that spherical planets will be used (there is no flat terrain capability).
I guess I should put it this way: It's the engine that makes the game possible, and the scripts that define what the game does, within the limits of the engine. The more limiting the engine, the smaller part the script has in contributing towards the "actual" game. For a very flexible engine, it would probably be fair to say the script is where you write the "actual" game. But for a specialized game engine (and all are specialized, just to different degrees), the script is only a small part of the whole game.