An unusual use-case for HMAC as compression function in web browsers
The collision resistance of this hash will be the collision resistance of $\operatorname{HMAC-SHA256}_{IV}(M)$. Beware of the fact that pre-hashing of the key is a thing with HMAC, so $$\operatorname{HMAC-SHA256}_{\text{ReallyLongIV}}(M)=\operatorname{HMAC-SHA256}_{\operatorname{SHA256}(\text{ReallyLongIV})}(M)$$


  Do I still need to include file length in the final block?


To get the benefits of the Merkle-Damgard proof? Yes, because abstractly your HMAC invocations are just compression function calls.
However if you're willing to assume that it's impossible / really hard to find $(IV',m')$ such that $\operatorname{HMAC-SHA256}_{IV'}(m')=IV_0$ then you don't need to pad with the message length. You see this when you follow the standard Merkle-Damgard proof. That is go backwards through the message and if at any point the inputs differ but the outputs match you got a collision in the underlying compression function. There will be a point where one message may be shorter than the other, assumning both end with the same suffix - because otherwise there would be a collision - both end up at $IV_0$ at some point and as one message is longer one of them must expose a preimage to $IV_0$.


  What are the characteristics of such construct with regard to length-extension attack?


It's a standard Merkle-Damgard, so it has the same length-extension weakness. To fix this you could e.g. use HAIFA and use $C(S,M,P)=\operatorname{HMAC-SHA256}_S(P\mathbin\|M)$ as HAIFA's compression function for some fixed-length integer $P$.