Repair-vs-replace tagging on repair-request items

[important-new]

repair_requests / repair_request_items (server/lib/db/schema/repair-request.ts) support per-defect credits, share tokens, and creator kind, but there is no repair-vs-replace field per item.

Scope: add a repair-vs-replace tag on repair-request items and surface it in the repair-request builder and the report.

[important-new]

Still open. Our own tracking said otherwise, and it was wrong — recording why,
because the mistake is more reusable than the correction.

Checked against main. repair_request_items carries: findingKey,
sectionTitle, itemLabel, commentSnapshot, requestedCreditCents, note.
There is no repair-vs-replace field. Nothing to surface in the builder or the
report yet, either.

Two ways this looked done, and neither survives contact with the schema.

1. A grep found a repair/replace enum — on the wrong table.
server/lib/db/schema/inspection/cost-items.ts has
action: text('action', { enum: ['repair', 'replace', 'further_study'] }). That
is the commercial cost-item line, a different feature on a different table.
Finding a match and treating it as the match is the failure; the issue names
server/lib/db/schema/repair-request.ts explicitly and that is the file that
had to be read.

2. The internal tracker had this issue filed under the wrong plan. It was
associated with the repair-note quick-insert work, which shipped quick phrases
for the note field. Same table, adjacent UI, entirely different feature — so
the plan's tasks completing made the issue look complete. A mis-mapping, not a
missed checkbox.

Scope is unchanged from the description: a repair-vs-replace tag on
repair_request_items, surfaced in the repair-request builder and in the report.

⚠️ One constraint that did not exist when this was filed: the repair-request
surface is now subject to the pricing boundary — the platform authors no monetary
values, and amounts in the buyer's list are buyer-entered and carry an authorship
attribution. A repair-vs-replace tag is a classification, not a price, so it is
unaffected — but whoever implements it should not quietly reintroduce a
cost-bearing field alongside it. lint:price-capability will refuse that anyway.