Escape special characters in default value table cells

[greymoth-jp]

Problem

When a parameter or property default value contains a pipe, it is written raw into the Default column of the generated table. The extra | is read as a column separator, so the row gets one cell too many. GitHub-flavoured markdown then drops the overflowing cell, which means the Description is silently lost.

This happens for any default value with a | in it, for example:

/**
 * @param {string} [sep="|"] - the separator to use
 * @param {RegExp} [re=/a|b/] - split pattern
 */
function join (sep, re) {}

Generated table (the descriptions never make it into the rendered output):

| Param | Type | Default | Description |
| --- | --- | --- | --- |
| [sep] | <code>string</code> | <code>"|"</code> | the separator to use |
| [re] | <code>RegExp</code> | <code>/a|b/</code> | split pattern |

Why this column and not the others

The Type column in the same table already protects against this. Union types are joined with an escaped \| delimiter, and each type name is run through the escape helper in link.hbs. So {string|number} renders as string \| number and stays inside its cell. The Default cell is the only value cell that emits its content without that escaping.

Fix

Run the default value through the existing escape helper, the same one the type cells use. I also changed escape() to return non-string input unchanged. It returned null before, and since default values can be numbers or booleans, escaping them directly would otherwise blank them out. The helper is only ever called on strings today, so this does not change any existing output.

After the change the pipe is escaped, the rows keep four cells, and the descriptions survive. Numeric and boolean defaults are unaffected. partials/partial-cache.js is regenerated via npm run partials.

npm test passes.

[greymoth-jp]

Closing this to clean up my open PRs. It's a small change and not really worth taking up your review time. Sorry for the noise.

[75lb]

We've come across this issue before and there was a reason the code remained the way it is - I can't just can't remember why so my first job was to track down the previous issue thread. But if you are closing, no big deal.