Fix normalizePort and consolidate delete handlers

[cubap]

This PR addresses two related issues:

• tinyNode.js normalizePort() is not doing okay #52 tinyNode.js normalizePort() is not doing okay

  • Moves the default port outside the normalizePort() call: const port = normalizePort(process.env.PORT) || 3002
  • Updates normalizePort() to validate that the value is an integer between 1 and 65535, returning false otherwise so .listen() always receives a number.

• Remove double DELETE handling #64 Remove double DELETE handling

  • Consolidates the two router.delete() handlers in routes/delete.js into a single deleteRecord handler that extracts the @id from either the path parameter or the request body and performs the delete.

Fixes #52
Fixes #64

[thehabes]

Manual verification (pm2 on :3002, running PR code against devstore)

#	Request	Result
T1	DELETE /delete body {"@id": <uri>}	502 404: .../v1/api/delete - This page does not exist
T2	DELETE /delete body {"id": <uri>}	502 (same as T1)
T3	DELETE /delete/:id	204, and the object shows __deleted
T4	DELETE /app/delete/:id (already deleted)	502 wrapping RERUM's 403
T5	DELETE /delete body {}	400
T6/T7	text/plain body, or no Content-Type	415
T8	GET /delete	405
T10	DELETE /delete/:id with a bogus caller Bearer token	401 passed through ✅
T11	Bodied delete with a bogus caller Bearer token	502 (the 404 hides the 401)

All of these match main indicating the code change did no improve upon main.

🔴 Critical Issue: #64 is not resolved

File: routes/delete.js:10-32
Category: Logic error / Incomplete scope

Problem:
T1, T2 and T11 confirm that the bodied form still cannot work. RERUM itself only defines DELETE /api/delete/:_id.

The handler does pull id out of the path or the body (line 10), but only uses it for the "missing id" check. It then branches on isPathDelete and still sends two different requests to RERUM:

• The path form calls delete/<id> with no body.
• The bodied form calls delete with a JSON body.

This is the "process both versions ... and send them in differently" that #64 asks to remove. The PR description says the handler "extracts the @id ... and performs the delete", but the extracted value is never used to build the request.

RERUM has no bodied delete endpoint, so every bodied DELETE /delete returns 502 (T1, T2). It also hides 401/403 responses for passthrough callers (T11). Fixing #64 as written would also fix #129 Finding 2.