fix: read res.headers so content-type params don't break header matchers

[abhu85]

Problem

Fixes #876.

If a response's Content-Type carries a header= parameter — which is valid for text/csv (RFC 7111: header=present / header=absent) — every header assertion breaks:

const s = createServer((_, res) => {
  res.setHeader('foo', 'a');
  res.setHeader('content-type', 'text/csv; header=a');
  res.end();
});
await request(s).get('/').expect('foo', 'a');
// Error: expected "foo" header field

Cause

_assertHeader reads the header from res.header:

const actual = res.header[field.toLowerCase()];

superagent's _setHeaderProperties copies every content-type parameter onto the response object (this[key] = parameters[key]). A parameter literally named header therefore overwrites res.header (normally the header map) with the string "a", so res.header[field] is undefined for every field. res.headers — the canonical header map — is left untouched.

Fix

Read from res.headers instead of res.header:

const actual = res.headers[field.toLowerCase()];

One line; res.headers is the same map superagent populates and isn't subject to the content-type-parameter clobbering.

Test plan

• Added a regression test in test/issue-fixes.js (Issue [fix] content-type with "header=" breaks all header matchers #876): a route returning Content-Type: text/csv; header=present — .expect('X-Custom', 'value') now passes.
• New test fails on master (expected "X-Custom" header field) and passes with the fix.
• Full suite 131 passing; eslint clean.